I'd like to be able to upload a cookbook to a Chef Server using a 'client' and not a 'user'. Is this supported? If not is it still technically possible? I did try but couldn't get it to work. I'll explain what I tried.
I went into my Org and created a group called 'test'. I then gave group 'test' list and create access to cookbooks in the Global Permissions.
I then created a client called 'uploader'. I then tried to add client 'uploader' to group 'test' but kept getting error of "Sorry, but that is not a valid member name". I was slightly confused as there is a group of 'clients' that has clients as a part of it, but it seems that you are not able to add clients to other groups. So I decided to get past this by using the knife-acl gem to extend knife. I then used knife to add the client 'uploader' to group 'test' and it shows properly in the Chef Server WebUI for my Org.
I then attempted to upload a cookbook with uploader but get error:
I've gone as far as giving group 'clients' create perms to cookbooks and get the same error as above.
So it seems it's really NOT possible for a client to upload a cookbook to a Chef Server ... but I wanted to know if someone smarter then me knew of a way or if this is perhaps a bug.
If it is not possible currently then should it be possible as you currently have the ability to set the perms up in a way on the Chef Server that would make you think you should be able to do it (as I described above).
Sorry to ask but: Why do you wish to allow a client (a node auth key) to upload cookbooks ?
The only workaround I can think of if setting the acl on the node for a user to update the node object and running chef as this user on this node. But I really donāt get the point or the use case.
I do not want a node or a client of a node to be able to upload but instead just a client. I want to be able to create a client as a sort of āservice accountā to be able to grant permissions to for automation tasks for that Org. The reason for this is I do not own the Chef Server I am using but do have access to my Org. Therefore I am not able to create users on the server to use without involving others (āThe Adminsā) but I can create a client that I could manage in my Org itself.
So I would like to be able to create a client, control its perms through groups and global perms, and then use that client for things like knife cookbook upload ... in automation tasks.
You can't do a knife user create within your org ? In this case I see no way, as the sandbox acl are not exposed in a way to allow clients to write in it.
I guess Iām not sure if I can create users in my Org. I assumed I wasnāt as the only option I see from the WebUI was to invite users to my Org. So I assumed (maybe incorrectly) that someone has to create/add a user to the Chef Server before someone is allowed to then invite that user to an Org.
I will try creating a user with the command you provided and see what happens.
So I think the main part of my issue is that the Chef Server Iām using is managed by another team and is tied to Active Directory (managed by yet another team), which is why itās more difficult to create a user ā¦ because it means adding a user to AD, then adding to an AD group ā¦ things which are wrapped up in processes and involve several teams.
This is why Iām trying to figure out a way to be able to manage my Org without the need to go through this headache. Was hoping clients would be the way to go since from a WebUI perspective you can architect perms in a way where it seems it should work ā¦ but sounding like it canāt. :ā(
I hope for you someone will prove me wrong, but I really feel the architecture of the chef-server does not allow it.
We had the problem after migrating from chef11 to chef12 for our jenkins instances wich were badly configured to use an admin client in chef11 (open source one). We fixed it by creating users.
Probably time to start yak shaving and asking for a new user
AD only applies to the manage console (web) and not the API. All API users/clients are managed internally by the Chef Server.
As for giving more permissions to a particular user or client, this is possible through the RBAC system. knife-acl is probably the best way to do this.
So Iāve been trying to get something working with knife-acl since it gives you more control then is available on the WebUI. But I still canāt seem to get a client able to upload a cookbook. I added client uploader to group test and gave group test perms of create,grant,update,delete,read for containers cookbooks. Here is what I have so far:
$ knife group show test
actors: uploader
clients: uploader
groupname: test
groups:
name: test
orgname: jmccann
users:
$ knife acl show containers cookbooks
create:
actors:
uploader
uploader2
pivotal
groups:
clients
users
admins
test
delete:
actors: pivotal
groups:
users
admins
test
grant:
actors: pivotal
groups:
admins
test
read:
actors:
uploader
uploader2
pivotal
groups:
clients
users
admins
test
update:
actors: pivotal
groups:
users
admins
test
But it still fails with:
$ knife cookbook upload oob_dhcp -o .
Uploading oob_dhcp [0.2.0]
ERROR: You authenticated successfully to https://mychefserver/organizations/jmccann as uploader but you are not authorized for this action
Response: missing create permission
Now I know it can work! Iāll play with cleaning my perms now down to what is really necessary since I was granting the world to uploader trying to get this to work.
I do have a quick question now though ā¦ what is the āsandboxesā container?
I pass there, I didnāt dig enough. I do think it is used to ensure a cookbook can be uploaded entirely before being moved to bookshelf. But thatās just a guess.
If I understood it properly, it only happens for new files, updated files (new versions of existing files) are stored in bookshelf directly (but I MAY be wrong here)
I do have a quick question now though ... what is the 'sandboxes' container?
A Sandbox is a temporary list of files that you intend to upload. The actual files you upload are stored in an S3-alike service (bookshelf) or real S3 (Hosted Chef does this, you can configure it on your own server as well if you wish). Therefore Chef Server needs a mechanism to know what files you've promised to upload while it waits for you to upload them to a separate service. That's what the sandbox does.
Itās quicker with knife
