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

kubeconfig appears in ansible log module invocations, even when in dictionary form #782

Open
jnm27 opened this issue Oct 8, 2024 · 7 comments
Labels
type/bug Something isn't working

Comments

@jnm27
Copy link

jnm27 commented Oct 8, 2024

SUMMARY

When passing the kubeconfig to various kubernetes.core modules as a dictionary instead of a path, it contains sensitive data and should not be logged.
I've patched this in our environment in the meantime to simply always no_log the kubeconfig argument in args_common.py.

ISSUE TYPE
  • Bug Report
COMPONENT NAME

kubernetes/core/plugins/module_utils/args_common.py

ANSIBLE VERSION
ansible [core 2.15.0]
  python version = 3.11.2 (main, Feb 17 2023, 09:28:16) [GCC 8.5.0 20210514 (Red Hat 8.5.0-18)] (/usr/bin/python3.11)
  jinja version = 3.1.2
COLLECTION VERSION
kubernetes.core          4.0.0
CONFIGURATION
not relevant
OS / ENVIRONMENT

RHEL8.6 ansible engine, Openshift 4.16 target.

STEPS TO REPRODUCE

Pass kubeconfig as a dictionary to any kubernetes.core module that uses args_common.py.

kubernetes.core.helm, community.okd.k8s
EXPECTED RESULTS

Sensitive kubeconfig dictionary is omitted from logs.

ACTUAL RESULTS

Kubeconfig dictionary is in plaintext in logs.

N/A
@yurnov
Copy link
Contributor

yurnov commented Oct 28, 2024

Hi @jnm27,

could you please give a more info, i.e. example of kubeconfig in the dictionary form (with hidden sensitive information) and example of output, and in the general, step to reproduce

@jnm27
Copy link
Author

jnm27 commented Oct 28, 2024

To reproduce, take the kubeconfig generated by the openshift installer for the system:admin user (for example). In Ansible, read that file and |from_yaml it to get it in a dictionary form, then pass that as the kubeconfig parameter to any kubernetes.core module that supports it. Will see the kubeconfig contents in the module invocation when running at a higher verbosity.

@yurnov
Copy link
Contributor

yurnov commented Oct 28, 2024

@jnm27,

I don't have any OpenShift cluster, is the difference compared to kubeconfig from any other K8s cluster?

@jnm27
Copy link
Author

jnm27 commented Oct 28, 2024

No difference - any kubeconfig would work. Just a difference of loading the contents of the file in ansible instead of passing the path to it directly.

@yurnov
Copy link
Contributor

yurnov commented Oct 28, 2024

Can you give an example (replacing sensitive parts with dummy data)?

@jnm27
Copy link
Author

jnm27 commented Oct 28, 2024

clusters:
- cluster:
    certificate-authority-data: <certificate base64>
    server: https://<api>:<port>
  name: <name>
contexts:
- context:
    cluster: <name>
    user: admin
  name: admin
current-context: admin
preferences: {}
users:
- name: admin
  user:
    client-certificate-data: <certificate base64>
    client-key-data: <key base64>

@yurnov
Copy link
Contributor

yurnov commented Oct 29, 2024

Ok, reproduced the concern mentioned above with the following:

---
- hosts: localhost
  gather_facts: false

  tasks:
    - name: Read content of kubecconfig
      ansible.builtin.slurp:
        src: /path/to/kubeconfig
      register: kubeconfig_content

    - name: Decode base64 encoded kubeconfig
     # Be aware that the content of kubeconfig will be shown in logs
      set_fact:
        kubeconfig: "{{ kubeconfig_content['content'] | b64decode | from_yaml }}"

    - kubernetes.core.helm_info:
        kubeconfig: "{{ kubeconfig }}"
        release_namespace: default
        release_name: my-release
        release_state: failed
      register: helm_info

When the playbook is running with -vvv (or more verbosity) key, Ansible will print module_args that will include uncensored kubeconfig, except in case when no_log: true is specified.

@gravesm gravesm added the type/bug Something isn't working label Oct 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type/bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants