API token chicken and egg problem
Nonspecialist
I'm generating Rundeck servers (using chef) for dynamically generated
virtual environments; I have a resource provider set up which reflects
dynamic changes to that environment (why, yes, it is a cloud
environment), and I want to be able to refresh the resource set when a
change happens.
Sounds easy, right? Use the API. But:
- API doesn't support password authentication -- you must use a token
- tokens can't be generated by users with less that admin or
user_admin roles (hardcoded)
- tokens can't be generated through the API itself, meaning a horrible
hack of screen-scraping to get them
- API calls to refresh resources require either admin or nodes_admin
roles (hardcoded)
- it's effectively impossible to set up a least privilege user for
refreshing content at the time the rundeck environment is built up;
one would have to:
-- create rundeck directory structure with 'refresh' user with
user_admin role
-- start rundeck
-- auth and screen scrape for the 'refresh' user to get the token
-- change the 'refresh' user's roles to remove user_admin and add
nodes_admin
-- restart rundeck
-- use the API to refresh the resources
Is there an easier way to do this? If not, it would make sense to me
to have:
- the ability to generate a token via the API using password
authentication; and/or
- the ability to call the API with password authentication instead of
a token; and/or
- the ability to set up a role which can refresh nodes without having
to be admin or nodes_admin; and/or
- the ability to create a token for a user without having to have the
user_admin role
I'm posting here instead of smashing in changes myself, because I
recognise that my Java/Groovy coding skills are roughly equivalent to
that of an epileptic monkey; I might get it right after bashing on the
keyboard enough, but it won't be pretty.
-- C.
Greg Schueler
API Password auth is still supported, (however not HTTP BASIC auth, perhaps that is what you meant?): http://rundeck.org/docs/api/index.html#password-authentication
Auth roles are actually not hardcoded. You can define mappings within the rundeck-config.properties file. e.g. to allow "some_role" the abilities of the internal "nodes_admin" role you would add:
mappedRoles.nodes_admin=some_role
See http://rundeck.org/docs/RunDeck-Guide.html#role-mapping
However, we are planning to fully move away from mapped roles to the ACL policy file authorization mechanism eventually, which should also give you more fine-grained control.
regarding other chicken/egg issues: perhaps a way to specify an API token at install-time would be useful? Or perhaps simply an out-of-band way of defining
an API token, such as writing a properties file to RDECK_BASE/etc?
it seems reasonable to have a way to generate an API token (assuming user is authorized for that) via password based API authentication. then the workflow could be: authentication with password, ask for or generate API token, use API token after that.
ideas for improving automation of RunDeck itself are always welcome: please add requests to lighthouse: http://rundeck.lighthouseapp.com/projects/59277-development/tickets/new
The restriction on requiring admin role for generating an API token is intended as a security measure when user authentication is performed via another system (such as LDAP). i.e. if a user is removed/deauthorized in LDAP, there's no way for RunDeck to know that their associated API tokens should be removed as well. We restricted it to admin role to put the onus of managing it on the admin's shoulders.
However, another solution might be for the API token auth to be de-coupled from user accounts. Essentially just an internal authentication system. However it would have to be adaptable to the various security requirements that people have.
--
Greg
Nonspecialist
Thanks for the fast reply! Responses inline.
On Aug 17, 11:17 am, Greg Schueler <g...@dtosolutions.com> wrote:
> Hi,
>
> API Password auth is still supported, (however not HTTP BASIC auth, perhaps that is what you meant?):http://rundeck.org/docs/api/index.html#password-authentication
(using curl even with a cookie-jar) it needs the jsessionid appended
to the URL at certain points.
>
> Auth roles are actually not hardcoded. You can define mappings within the rundeck-config.properties file. e.g. to allow "some_role" the abilities of the internal "nodes_admin" role you would add:
> mappedRoles.nodes_admin=some_role
>
> Seehttp://rundeck.org/docs/RunDeck-Guide.html#role-mapping
some roles:
301 def performNodeReload = {String url=null->
302 if(params.project){
303 if(roleService.isUserInAnyRoles(request,
['admin','nodes_admin'])){
304 Framework framework =
frameworkService.getFrameworkFromUserSession(session,request)
305 def
project=framework.getFrameworkProjectMgr().getFrameworkProject(params.project)
>
> However, we are planning to fully move away from mapped roles to the ACL policy file authorization mechanism eventually, which should also give you more fine-grained control.
>
> regarding other chicken/egg issues: perhaps a way to specify an API token at install-time would be useful? Or perhaps simply an out-of-band way of defining
> an API token, such as writing a properties file to RDECK_BASE/etc?
probably be best, since if you have rights to change the filesystem
that rundeck is installed to, you effectively have rights to fiddle
with rundeck itself. It's also easier to verify that the token is
created at install time (thinking of integration with chef recipes
here)
>
> it seems reasonable to have a way to generate an API token (assuming user is authorized for that) via password based API authentication. then the workflow could be: authentication with password, ask for or generate API token, use API token after that.
generate a token below.
>
> ideas for improving automation of RunDeck itself are always welcome: please add requests to lighthouse:http://rundeck.lighthouseapp.com/projects/59277-development/tickets/new
>
> The restriction on requiring admin role for generating an API token is intended as a security measure when user authentication is performed via another system (such as LDAP). i.e. if a user is removed/deauthorized in LDAP, there's no way for RunDeck to know that their associated API tokens should be removed as well. We restricted it to admin role to put the onus of managing it on the admin's shoulders.
rundeck continue to use LDAP for authorization (not authentication) of
that user? Because if not, you now have two sources of truth for
whether an account is active or not.
>
> However, another solution might be for the API token auth to be de-coupled from user accounts. Essentially just an internal authentication system. However it would have to be adaptable to the various security requirements that people have.
(basically, application accounts exist on machine instances, not in
LDAP), but having a completely decoupled token mechanism (ie the token
isn't associated with a user account) would make a lot of the
semantics around "this account did this at that time" a lot harder to
resolve. So long as JAAS can handle things like local accounts first,
then LDAP (and I believe it can, I just haven't got that far yet),
we'll be ok.
-- C.
Greg Schueler
On Aug 16, 2011, at 6:58 PM, Nonspecialist wrote:
> Hey Greg,
>
> Thanks for the fast reply! Responses inline.
>
> On Aug 17, 11:17 am, Greg Schueler <g...@dtosolutions.com> wrote:
>> Hi,
>>
>> API Password auth is still supported, (however not HTTP BASIC auth, perhaps that is what you meant?):http://rundeck.org/docs/api/index.html#password-authentication
>
> Yeah, after retrying this I managed to get it to work; it seems like
> (using curl even with a cookie-jar) it needs the jsessionid appended
> to the URL at certain points.
strange, there are a number of curl based test scripts under test/api in the source base, that can test the API using either password or token authentication. the password auth simply uses a cookie file throughout.
>
>>
>> Auth roles are actually not hardcoded. You can define mappings within the rundeck-config.properties file. e.g. to allow "some_role" the abilities of the internal "nodes_admin" role you would add:
>> mappedRoles.nodes_admin=some_role
>>
>> Seehttp://rundeck.org/docs/RunDeck-Guide.html#role-mapping
>
> Yes, but in FrameworkController.groovy, line 303 seems to hardcode
> some roles:
>
> 301 def performNodeReload = {String url=null->
> 302 if(params.project){
> 303 if(roleService.isUserInAnyRoles(request,
> ['admin','nodes_admin'])){
> 304 Framework framework =
> frameworkService.getFrameworkFromUserSession(session,request)
> 305 def
> project=framework.getFrameworkProjectMgr().getFrameworkProject(params.project)
>
the call to roleService.isUserInAnyRoles does use the role mapping to determine the result. those hardcoded names are the Application Roles (i.e. internal names) mentioned in the referenced docs.
>>
>> However, we are planning to fully move away from mapped roles to the ACL policy file authorization mechanism eventually, which should also give you more fine-grained control.
>
> Yeah, that'll be nice.
>
>>
>> regarding other chicken/egg issues: perhaps a way to specify an API token at install-time would be useful? Or perhaps simply an out-of-band way of defining
>> an API token, such as writing a properties file to RDECK_BASE/etc?
>
> Yes, that would work well too; writing it to a properties file would
> probably be best, since if you have rights to change the filesystem
> that rundeck is installed to, you effectively have rights to fiddle
> with rundeck itself. It's also easier to verify that the token is
> created at install time (thinking of integration with chef recipes
> here)
>
>>
>> it seems reasonable to have a way to generate an API token (assuming user is authorized for that) via password based API authentication. then the workflow could be: authentication with password, ask for or generate API token, use API token after that.
>
> That would work too ... I'll respond to the need for admin access to
> generate a token below.
>
>>
>> ideas for improving automation of RunDeck itself are always welcome: please add requests to lighthouse:http://rundeck.lighthouseapp.com/projects/59277-development/tickets/new
>>
>> The restriction on requiring admin role for generating an API token is intended as a security measure when user authentication is performed via another system (such as LDAP). i.e. if a user is removed/deauthorized in LDAP, there's no way for RunDeck to know that their associated API tokens should be removed as well. We restricted it to admin role to put the onus of managing it on the admin's shoulders.
>
> I may not be understanding here; after you generate an API token, does
> rundeck continue to use LDAP for authorization (not authentication) of
> that user? Because if not, you now have two sources of truth for
> whether an account is active or not.
No, API token authentication is done outside of the container authentication (such as LDAP), and so authorization is as well. essentially API token requests are given only role membership of a fake role "api_token_group". Yes, it is two sources of truth for access, and for this reason we nearly scrapped the api token auth, but instead just limited it to admin users.
the alternative is password based auth, and perhaps there could be a hybrid mode (using the generate-token auth workflow) where e.g. time-limited API tokens could be granted.