Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[CLI] add the ability to specify a description for tokens generated with awx login #6122

Closed
Elyytscha opened this issue Feb 28, 2020 · 11 comments

Comments

@Elyytscha
Copy link

ISSUE TYPE
  • Bug Report
SUMMARY
ENVIRONMENT
  • AWX version: 9.0.2
  • AWX install method: docker-compose
  • Ansible version: 2.9+
  • Operating System:
  • Web Browser:
STEPS TO REPRODUCE

use cli like the following:
awx --conf.username user --conf.password password tokens create test --scope write --description "automated token generation" -k

EXPECTED RESULTS

successfull token creation

ACTUAL RESULTS
bash-5.0$ awx --conf.username user --conf.password password tokens create test --scope write --description "autmoated token generation" -k
usage: awx [--help] [--version] [--conf.host https://example.awx.org] [--conf.token TEXT] [--conf.username TEXT] [--conf.password TEXT] [-k] [-f {json,yaml,jq,human}]
           [--filter TEXT] [--conf.color BOOLEAN] [-v]
           resource ...

positional arguments:
  resource
    login               authenticate and retrieve an OAuth2 token
    config              print current configuration values
    ping
    instances (instance)
    instance_groups (instance_group)
    config
    settings (setting)
    me
    organizations (organization)
    users (user)
    projects (project)
    project_updates (project_update)
    teams (team)
    credentials (credential)
    credential_types (credential_type)
    credential_input_sources
    applications (application)
    tokens
    metrics
    inventory (inventories)
    inventory_scripts (inventory_script)
    inventory_sources (inventory_source)
    inventory_updates (inventory_update)
    groups (group)
    hosts (host)
    job_templates (job_template)
    jobs (job)
    job_events
    ad_hoc_commands (ad_hoc)
    system_job_templates
    system_jobs
    schedules (schedule)
    roles (role)
    notification_templates (notification_template)
    notifications
    labels (label)
    unified_job_templates
    unified_jobs
    activity_stream
    workflow_job_templates (workflow)
    workflow_jobs (workflow_job)
    workflow_approvals
    workflow_job_template_nodes (node)
    workflow_job_nodes

optional arguments:
  --help                prints usage information for the awx tool
  --version             display awx CLI version

authentication:
  --conf.host https://example.awx.org
  --conf.token TEXT     an OAuth2.0 token (get one by using `awx login`)
  --conf.username TEXT
  --conf.password TEXT
  -k, --conf.insecure   Allow insecure server connections when using SSL

output formatting:
  -f {json,yaml,jq,human}, --conf.format {json,yaml,jq,human}
                        specify an output format
  --filter TEXT         specify an output filter (only valid with jq or human format)
  --conf.color BOOLEAN  Display colorized output. Defaults to True
  -v, --verbose         print debug-level logs, including requests made

Valid credentials were not provided.
$ awx login --help
ADDITIONAL INFORMATION

i cant use awx login, because there i can not specify a description for the token
and another problem is, awx login creates everytime a new token, so with a jenkins which triggers a container run which has the awx cli login implemented via user // password, every jenkins trigger will result in a new Oauth token on the account, so somehow i have to delete the token after i created and used it for his purpose, therefore i want to get ids where description == automated tokens and delete those tokens found by id, so i thought i could to this over awx token create, but there the --conf.username --conf.password params are not recognized

on the other side, using only oauth token for ci/cd is not an option, because it has an expire date, so ci/cd will stop working after ~months because oauth token is expired

@Elyytscha
Copy link
Author

Elyytscha commented Feb 28, 2020

my current workaround is to use awx login and do delete every token with desc "Tower CLI" after ci/cd tower job has run but that means if someone has created an Oauth token via awx login by hand, the next ci/cd run will remove this token if ci/cd is triggered lokal with the users ad user which created first the token

@ryanpetrello
Copy link
Contributor

Are you just trying to generate an OAuth2.0 token, given some username and password?

https://docs.ansible.com/ansible-tower/latest/html/towercli/authentication.html#generating-a-personal-access-token

~ env | grep TOWER_
TOWER_VERIFY_SSL=f
TOWER_HOST=https://example.awx.org:8043
TOWER_USERNAME=ryan
TOWER_PASSWORD=ryan

~/dev/awx awx login
{
     "token": "Ym1QA9RMzSolp1XCXC0SE9U0gHGUfK"
}
~ unset TOWER_USERNAME
~ unset TOWER_PASSWORD
~ TOWER_TOKEN=Ym1QA9RMzSolp1XCXC0SE9U0gHGUfK awx me | jq '.results[].username'
"ryan"

@ryanpetrello
Copy link
Contributor

awx login -h
usage: awx login [-h] [--conf.client_id TEXT] [--conf.client_secret TEXT]
                 [--conf.scope {read,write}]
                 [--conf.host https://example.awx.org] [--conf.token TEXT]
                 [--conf.username TEXT] [--conf.password TEXT] [-k]

optional arguments:
  -h, --help            show this help message and exit

OAuth2.0 Options:
  --conf.client_id TEXT
  --conf.client_secret TEXT
  --conf.scope {read,write}

authentication:
  --conf.host https://example.awx.org
  --conf.token TEXT     an OAuth2.0 token (get one by using `awx login`)
  --conf.username TEXT
  --conf.password TEXT
  -k, --conf.insecure   Allow insecure server connections when using SSL

@Elyytscha
Copy link
Author

as i already said, awx login has no option to specify the description of the token

so i can hang up on description = "Tower CLI" because this is the description awx login is adding

but that means that if i remove the autogenerated OAuth Tokens after ci/cd finished the tower job, i will remove all OAuth Tokens for the user with description == "Tower CLI"

so if a user triggers a manual awx login + job, the next automated ci/cd run for this user will remove his manual created token by awx login

so i wanted to create a oauth token with another description then "Tower CLI" from input username:password but this is only possible if i have issued a valid oauth token via awx login ..

/reopen

@Elyytscha
Copy link
Author

what i do is basically the following:

...
shift
if [[ "$1" = "token" ]]; then
    shift
    ...
    TOWER_TOKEN=${6}
    ...
elif [[ "$1" = "user" ]]; then
    shift
    DEPLOYMENT_METHOD=user
    ...
    TOWER_USERNAME=${6}
    TOWER_PASSWORD=${7}
    echo $(awx login -f human -k ) > /tmp/TOWER_TOKEN && . /tmp/TOWER_TOKEN && rm /tmp/TOWER_TOKEN
fi
...
DEPLOY_CMD="job_templates launch "ans-${PROJ}-deploy" --extra_vars @${VARS_FILE} --monitor ${ARGS}"
awx -k ${DEPLOY_CMD}
if [ "${DEPLOYMENT_METHOD}" == "user" ]; then
    TOWER_CLI_TOKEN_IDS=$(awx -k tokens list -f json | jq '.results[] | select(.description=="Tower CLI") | .id')
    echo ${TOWER_CLI_TOKEN_IDS} | while IFS= read -r line ; do awx tokens delete ${line} -k ; done
fi
...

so if i use awx login lokal to get a token
using this token to deploy via token method --> will work
if i deploy via username/password method --> will work
now all tokens with description "Tower CLI" will get removed
if i deploy now via token (like the first time) token is removed and deployment fails

thats why i want a method to issue a valid oauth token with a custom description from input: --> username:password

@ryanpetrello
Copy link
Contributor

Ah, so you just want to customize the description for the generated token?

@ryanpetrello ryanpetrello reopened this Feb 28, 2020
@Elyytscha
Copy link
Author

Elyytscha commented Feb 28, 2020

yep that would be a fix for my usecase, sorry for my bad first approach to explain the problem

but also a fix would be to make "awx tokens create" support --conf.username TEXT --conf.password TEXT

AND i wanted to point out that, maybe this behavior needs a rethink:
10x awx login will produce 10x a new Oauth token (to bruteforce // guess // hack 1 valid token from 10 is easier then to bruteforce the one and only valid oauth token)

actually what i want is to ensure that 100 ci/cd runs (with 100x awx login) will not leave 100 valid access tokens behind on awx

@ryanpetrello
Copy link
Contributor

Generally speaking, we don't intend people to constantly run awx login and generate a new token; rather, it's better to use awx login once to generate (and store) a token, which you reuse.

I think this PR might give you what you need. Mind giving it a shot?

#6124

@ryanpetrello ryanpetrello changed the title [CLI] awx tokens not taking up ENV vars for TOWER_USERNAME or TOWER_PASSWORD and also does not accpet --conf.username --conf.password [CLI] add the ability to specify a description for tokens generated with awx login Feb 28, 2020
@kdelee kdelee self-assigned this Mar 3, 2020
@kdelee
Copy link
Member

kdelee commented Mar 3, 2020

works for me, closing

@Elyytscha
Copy link
Author

Generally speaking, we don't intend people to constantly run awx login and generate a new token; rather, it's better to use awx login once to generate (and store) a token, which you reuse.

I think this PR might give you what you need. Mind giving it a shot?

#6124

how do you ensure that an ldap user which got disabled yesterday is not able to use awx with a token he ingested last week?

the only safe way at the moment to ensure that the user has valid rights for using awx is to log him in via username // password in an ldap setup

(i tested the patch with a custom dockerfile which applys those changes via sed onto the dockerhub images, also works for me)

@ryanpetrello
Copy link
Contributor

https://docs.ansible.com/ansible-tower/latest/html/administration/oauth2_token_auth.html

The Allow External Users to Create Oauth2 Tokens (ALLOW_OAUTH2_FOR_EXTERNAL_USERS in the API) setting is disabled by default. External users refer to users authenticated externally with a service like LDAP, or any of the other SSO services. This setting ensures external users cannot create their own tokens. If you enable then disable it, any tokens created by external users in the meantime will still exist, and are not automatically revoked.

By default, AWX doesn't allow LDAP users to create tokens for this very reason; if at all possible, you may want to consider managing explicit service accounts with tokens in your AWX install instead of user/pass auth.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants