Open CVE against the kubernetes connection plugin

[abadger]

SUMMARY

There is an unembargoed security issue with the kubectl connection plugin:

https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2020-1753

The kubectl connection plugin has two parameters that hold secret data:

• kubectl_password https://github.com/ansible-collections/kubernetes/blob/master/plugins/connection/kubectl.py#L108
• kubectl_token https://github.com/ansible-collections/kubernetes/blob/master/plugins/connection/kubectl.py#L118

In addition, the kubectl_extra_args argument could be passed a password and token: https://github.com/ansible-collections/kubernetes/blob/master/plugins/connection/kubectl.py#L63

All three of these parameters are passed to the kubectl command on the command line. Any user on the system can then read the secret information with a simple call to ps as command line arguments are not hidden from other users.

ISSUE TYPE

• Bug Report

COMPONENT NAME

• lib/ansible/plugins/connection/kubectl.py

ANSIBLE VERSION

All

CONFIGURATION

N/A

OS / ENVIRONMENT

N/A

ADDITIONAL INFORMATION

There appears to be a couple ways to fix this:

• The password and token appear to be settable in the configuration file: (Note: Do not use this command line in the plugin either as it will just shift the problem from one command line invocation to another. Just use that to see where the token and password will land in the configuration) https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-set-credentials-em- so you can put the password and token into a configuration file instead of handing it over on the command line. Make sure that the configuration file is mode 0600 so that it closes the hole.

  • The kubectl connection plugin does take a config file parameter already so you will have to work out whether you can pass kubectl two config files or whether you'll have to create a temporary config file which merges the user specified one with the password or token.

  • Also be sure to delete the temporary config file afterwards. If ansible is interrupted with kill -9, the config file could be left laying around. However, since unix permissions protect the file and do not protect the process list, breaking into the config file would require a privileged account on the box, not just a normal user account so this is preferable.

• Remove the token and password options. I hear that you are planning to release a backwards incompatible version of the collection. This is the ideal time to get rid of the CVE by removing these options. People who need to use token or password can put them into their own config file so they can still handle those use cases, just without the vulnerability.

Both of the above only address the specific password and token field. As noted above, the extra-args field can also contain the password and token. To close that hole you should add code to scan the extra args for password and token command line options. if found, the connection plugin should either error (my preference if you are making a backwards incompatible release) or warn that using password and token in extra-args is insecure.

[geerlingguy]

@abadger is this related to @bcoca's fix here? #51

[geerlingguy]

Remove the token and password options. I hear that you are planning to release a backwards incompatible version of the collection. This is the ideal time to get rid of the CVE by removing these options. People who need to use token or password can put them into their own config file so they can still handle those use cases, just without the vulnerability.

I have never used these options and am very happy to get rid of them, however I believe that many people who use OpenShift might use/require them? Not sure the specific use case but that's all I remember seeing in past issues...

[geerlingguy]

Responding to myself from earlier: https://bugzilla.redhat.com/show_bug.cgi?id=1811008#c11 does mention #51 as the upstream fix.

However, that doesn't change anything in Ansible 2.7.x, 2.8.x, or 2.9.x, since this collection has been forked from there.

[abadger]

#51 is not a fix. It only documents the problem.

People may be using them but no one should require them as they can add the password and token into a config file on their own instead of specifying them where they will be used on the command line.