passwords leaking on the command line

[Thomas Goirand]

Here:

https://github.com/openstack/puppet-keystone/blob/master/manifests/init.pp#L981-L989

puppet-keystone is passing the password through the command line instead of using an env var. As a result, the passwords are leaking in /proc.

As this is an OpenStack deployment on probably not multi-user machine, it's probably only a wishlist bug, but it'd still be nice to use env var instead, with something like this:

        export OS_BOOTSTRAP_USERNAME=${ADMIN_USER_NAME}
        export OS_BOOTSTRAP_PROJECT_NAME=${ADMIN_PROJECT_NAME}
        export OS_BOOTSTRAP_PASSWORD=${ADMIN_USER_PW}
        keystone-manage bootstrap

The same way, OS_TOKEN can be used, if OpenStack admin credentials (ie: an openrc.sh) are used:

        OS_TOKEN=$(openstack token issue -c id -f value) openstack service create ...

Thanks for considering this.

[Emilien Macchi (emilienm)]

This is not a security issue because it's highly advised to disable admin auth token after a deployment, like you can do with this class:
https://github.com/openstack/puppet-keystone/blob/master/manifests/disable_admin_token_auth.pp

All production deployments should run this class so the admin auth token can't be used anymore after an initial deployment.

[Matt Fischer (mfisch)]

Won't environ leak through /proc/PID/environ too?

[Thomas Goirand (thomas-goirand)]

Emilien, I don't think you get it. Using "keystone-manage bootstrap" is the way forward, but we should avoid using the --os-password there. This has nothing to do with using the admin auth token: you just happen to use the admin auth token value to do the admin bootstrap, but it has nothing to do with using passwords on the command line or not.

Matt, no, the environment variables wont leak, because /proc/PID/environ is only accessible by root, not even by the user who started the process. Though the parameters to command lines do appear in a "ps axuf" for every user connected. Doing export X=Y is a built-in command, so it wont appear in a ps.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/559063

[Tobias Urdin (tobias-urdin)]

The openstacklib helper and most of the providers for the modules support running the actual command with a service token that is obtained with environment variables.

To make everything actually start using this would be a very major work and probably require changes in all modules.

Even then we would still be stuck with for example `openstack user create ... --password secret` and similar calls for providers which I assume we could work around, but still would be a lot of manual work.

If anybody would like to step up to such a major write up I would be for it.

[Thomas Goirand (thomas-goirand)]

Tobias,

Yes, running --passsword secret to setup a user is bad, and probably should be fixed, I agree. However, here I was talking about the admin password leaking, that's IMO a way more important than a regular user (or service) password. And to fix this, the only thing you got to do is running:

export OS_BOOTSTRAP_USERNAME=admin \
export OS_BOOTSTRAP_PROJECT_NAME=admin \
export OS_BOOTSTRAP_PASSWORD=my-secret-password \
keystone-manage bootstrap --bootstrap-role-name admin

I fail to see how complicated that is. Could you explain?

[Tobias Urdin (tobias-urdin)]

Hello Thomas,

I wanted to point out that masking the usage of for example "user create" --password call is currently not possible with openstack client.

The bootstrap process is addressed here [1].

The major thing to fix here is that all providers is calling the openstack client with --os-username and --os-password. Example for keystone when managing a user with keystone_user provider we would still issue a "--os-username admin --os-password secret user list".

Same goes for all other providers however those are service users, example for nova_flavor would be "--os-password nova --os-password secret flavor list" but as you say maybe leaking the service user is not as bad as the admin user, it's still has possible higher privileges though and is a security issue/risk.

So my points is basically, it's a lot of work to rewrite all the providers but I would love it anybody had the time to work on it. But right now restricting access to the machines that are running your control plane should prevent it in the first place.

Best regards

[1] https://review.openstack.org/#/c/559063/

[Thomas Goirand (thomas-goirand)]

Tobias,

You can fix this also using environment values, just like when you're using openrc.sh:

export OS_USER_DOMAIN_ID=default \
export OS_USERNAME=admin \
export OS_PASSWORD=my-secret-password \
export OS_PROJECT_NAME=admin \
openstack project create --or-show service --description "Service project"

and same for roles, users, etc.

Thanks for the above patch which I approved. By the way, the bootstrap of Keystone should use all of its parameters if possible. Something like this:

export OS_BOOTSTRAP_USERNAME=${ADMIN_USER_NAME} \
export OS_BOOTSTRAP_PROJECT_NAME=${ADMIN_TENANT_NAME} \
export OS_BOOTSTRAP_PASSWORD=${ADMIN_USER_PW} \
keystone-manage bootstrap --bootstrap-role-name admin \
--bootstrap-service-name keystone \
--bootstrap-region-id ${REGION_NAME} \
--bootstrap-admin-url ${PROTO}://${KEYSTONE_ENDPOINT_IP}:35357 \
--bootstrap-public-url ${PROTO}://${KEYSTONE_ENDPOINT_IP}:5000 \
--bootstrap-internal-url ${PROTO}://${KEYSTONE_ENDPOINT_IP}:5000

In fact, it's even easier to do this way compared to the traditional way of creating the first admin user and then create the Keystone endpoint. I don't even know how puppet can do it the old way and continue to work.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/559063
Committed: https://git.openstack.org/cgit/openstack/puppet-keystone/commit/?id=b933d0bd1a69628f263d59894dd5f217415d45da
Submitter: Zuul
Branch: master

commit b933d0bd1a69628f263d59894dd5f217415d45da
Author: Tobias Urdin <email address hidden>
Date: Thu Apr 5 14:15:39 2018 +0200

    Use OS_BOOTSTRAP_PASSWORD instead of passing CLI

    When bootstrapping use environment variable
    OS_BOOTSTRAP_PASSWORD instead of passing password
    over CLI since it's a possible leak.

    Change-Id: I69783f75600048b9c4b2abb445b59e135029f3df
    Partial-Bug: 1557790

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/queens
Review: https://review.openstack.org/574114

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/pike
Review: https://review.openstack.org/574115

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/574115
Committed: https://git.openstack.org/cgit/openstack/puppet-keystone/commit/?id=1bbf75097295c73b37e99a39a8d9b4d1c0629e61
Submitter: Zuul
Branch: stable/pike

commit 1bbf75097295c73b37e99a39a8d9b4d1c0629e61
Author: Tobias Urdin <email address hidden>
Date: Thu Apr 5 14:15:39 2018 +0200

    Use OS_BOOTSTRAP_PASSWORD instead of passing CLI

    When bootstrapping use environment variable
    OS_BOOTSTRAP_PASSWORD instead of passing password
    over CLI since it's a possible leak.

    Change-Id: I69783f75600048b9c4b2abb445b59e135029f3df
    Partial-Bug: 1557790
    (cherry picked from commit b933d0bd1a69628f263d59894dd5f217415d45da)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/574114
Committed: https://git.openstack.org/cgit/openstack/puppet-keystone/commit/?id=86d5d56526cb6982f609a72099e8b7e97a8233d6
Submitter: Zuul
Branch: stable/queens

commit 86d5d56526cb6982f609a72099e8b7e97a8233d6
Author: Tobias Urdin <email address hidden>
Date: Thu Apr 5 14:15:39 2018 +0200

    Use OS_BOOTSTRAP_PASSWORD instead of passing CLI

    When bootstrapping use environment variable
    OS_BOOTSTRAP_PASSWORD instead of passing password
    over CLI since it's a possible leak.

    Change-Id: I69783f75600048b9c4b2abb445b59e135029f3df
    Partial-Bug: 1557790
    (cherry picked from commit b933d0bd1a69628f263d59894dd5f217415d45da)