I wanted to follow up to this email as I've made some headway. I've
also had a few recommendations from other folks and emailed with Seth
Falcon about it offlist.
Specifically around the OHC/OPC API calls to do this, it's worth
looking at Seth's 'knife-acl' gem on github (it's not on Rubygems
yet):
Be careful with this gem as you can seriously screw up your perms if
you aren't cautious. I did once already trying to use it from outside
the knife command line (My need was to generate the api calls myself).
Otherwise it's pure awesomesauce.
Specifically around creating a client that has the permissions needed
to mimic OSC admin clients, there are a few ways you can do it. The
main difference between the permissions that I've found thus far are
that admin clients created in OHC/OPC don't have the ability to
interact with OTHER clients. It can't create clients and in fact it
can't even LIST clients.
-
The easiest way to do this is to create a special group for your
extra admin-y client keys and grant that group the same permissions as
the admin group.
-
The other way is to grant your new client access to create and read
clients. The trick here to do this when making api calls is to use the
containers/clients/_acl path. Note that the name of the permission is
displayed differently in the console than in the API. It's called
"List" in the console but the API calls it read permission.
This still however doesn't give you access to DELETE nodes. That
permission isn't (that I've found) exposed in the console the same way
list and create are.
This might only be possible via an API call but I didn't get that far today.
Opscoders feel free to point out any errors in what I've said and if
anyone else is struggling with this task programmatically, the
knife-acl gem is the best place to look for examples.
On Wed, Aug 15, 2012 at 11:15 PM, John E. Vincent (lusis)
lusis.org+chef-list@gmail.com wrote:
Hey gang,
We're currently working through some issues with our code as it
interacts with hosted chef. Long story short, we use credentials
provided by the user to create our own API client. the problem here is
that an API client with admin privileges on OSS chef-server are NOT
the same as an API client with admin privileges on Hosted (and likely
Private) chef-server.
We need to be able to programmatically grant our new admin client
permissions to CRUD nodes and clients.
I'm not finding a lick of documentation around that ANYWHERE. I can
sort of understand why. I've even gone poking at what erlang code has
been released trying to dig it up.
Is it even possible to do it via the API?
Thanks!
John E. Vincent
@lusis