`kubernetes.core.k8s_info` redacts data when using in-memory kubeconfig

[h3nryc0ding]

SUMMARY

Since the release of version 5.1, the kubernetes.core.k8s_info module redacts portions of retrieved data when an in-memory kubeconfig is used.

ISSUE TYPE

• Bug Report

COMPONENT NAME

kubernetes.core.k8s_info

ANSIBLE VERSION

ansible [core 2.18.2]
  config file = None
  configured module search path = ['/Users/<>/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /Users/<>/gitlab/scratch/.venv/lib/python3.13/site-packages/ansible
  ansible collection location = /Users/<>/.ansible/collections:/usr/share/ansible/collections
  executable location = /Users/<>/gitlab/scratch/.venv/bin/ansible
  python version = 3.13.1 (main, Dec  3 2024, 17:59:52) [Clang 16.0.0 (clang-1600.0.26.4)] (/Users/<>/gitlab/scratch/.venv/bin/python3.13)
  jinja version = 3.1.5
  libyaml = True

COLLECTION VERSION

$ ansible-galaxy collection list kubernetes.core
Collection      Version
--------------- -------
kubernetes.core 5.1.0 

CONFIGURATION

CONFIG_FILE() = None
PAGER(env: PAGER) = less

GALAXY_SERVERS:

OS / ENVIRONMENT

• MacOS
• RHEL 9.5

STEPS TO REPRODUCE

Use an in-memory kubeconfig to retrieve a ConfigMap using kubernetes.core.k8s_info:

- name: Reproduce bug
  hosts: localhost
  tasks:
    - name: Load kubeconfig as dict
      ansible.builtin.set_fact:
        kubeconfig: "{{ lookup('file', '/Users/<>/.kube/config') | from_yaml }}"

    - name: Create CM
      kubernetes.core.k8s:
        kubeconfig: "{{ kubeconfig }}"
        namespace: default
        definition:
          apiVersion: v1
          kind: ConfigMap
          metadata:
            name: example
          data:
            example-one: Configuration
            example-two: v1-something

    - name: Retrieve CM (in-memory)
      kubernetes.core.k8s_info:
        kubeconfig: "{{ kubeconfig }}"
        namespace: default
        kind: ConfigMap
        name: example
      register: cm

    - name: Assert CM content
      ansible.builtin.assert:
        that:
          - cm['resources'][0]['data']['example-one'] == '********uration'
          - cm['resources'][0]['data']['example-two'] == '********-something'

    - name: Retrieve CM (file)
      kubernetes.core.k8s_info:
        namespace: default
        kind: ConfigMap
        name: example
      register: cm

    - name: Assert CM content
      ansible.builtin.assert:
        that:
          - cm['resources'][0]['data']['example-one'] == 'Configuration'
          - cm['resources'][0]['data']['example-two'] == 'v1-something'

EXPECTED RESULTS

The kubernetes.core.k8s_info module should return the correct data without redaction:

data:
  example-one: Configuration
  example-two: v1-something

ACTUAL RESULTS

The module redacts part of the returned data when using an in-memory kubeconfig:

data:
  example-one: ********uration
  example-two: ********-something

ADDITIONAL INFORMATION

• Running kubectl get cm example -o yaml correctly retrieves the full, unredacted data.
• This issue only occurs when using an in-memory kubeconfig.
• Using a file-based kubeconfig does not result in redaction.

[yurnov]

It seems that this issue was introduced by #826

Could you please try to edit plugins/module_utils/args_common.py on your env and replace on line 22 the:

    "kubeconfig": {"type": "raw", "no_log": True},

to the

    "kubeconfig": {"type": "raw"},

and check result.

[h3nryc0ding]

Removing "no_log": True resolved the issue on my end, so it seems the bug is related to this.

[loicortola]

Same here, by looking at #782 it really comes down to the same issue (and resolution).
This behaviour is pretty interesting:

• kubeconfig is indeed a file that contains some secrets / certificates
• it also contains many "standard" key / values which aren't secret, and the fact that they are standard (values such as "aws", "Config", etc...) makes it impossible to use as no_log content.

I would recommend:

• Rolling back this feature because the drawbacks makes it impossible to use Ansible to do much config-management on k8s
• Implement a more fine-grained kubeconfig "log / no_log" policy based on the keys (the sensitive keys are always the same in the object, so those values could be part of a no_log policy, but not the others) in the future.

WDYT?