Uploaded image for project: 'RHEL'
  1. RHEL
  2. RHEL-30183

podman role should support containers-auth.json

    • rhel-system-roles-1.78.1-0.1.el9
    • 4
    • sst_system_roles
    • 5
    • QE ack, Dev ack
    • False
    • Hide

      None

      Show
      None
    • Yes
    • Red Hat Enterprise Linux
    • System Roles Sprint 1, System Roles Sprint 2, System Roles Sprint 3, System Roles Sprint 4
    • Enhancement
    • Hide
      .New variable in the `podman` RHEL system role: `podman_credential_files`

      Some operations need to pull container images from registries in an automated or unattended way and cannot use the `podman_registry_username` and `podman_registry_password` variables.

      Therefore, the `podman` RHEL system role now accepts the `containers-auth.json` file to authenticate against container image registries. For that purpose, you can use the following role variable:

      `podman_credential_files` (list of dictionary elements):: Each dictionary element in the list defines a file with user credentials for authentication to private container image registries. For security, encrypt these credentials using the Ansible Vault feature. You can specify file name, mode, owner, group of the file, and can specify the contents in different ways. See the role documentation for more details.

      As a result, you can input container image registry credentials for automated and unattended operations.

      For more details, see the resources in the `/usr/share/doc/rhel-system-roles/podman/` directory. Alternatively, you can review the `containers-auth.json(5)` and `containers-registries.conf(5)` manual pages.
      Show
      .New variable in the `podman` RHEL system role: `podman_credential_files` Some operations need to pull container images from registries in an automated or unattended way and cannot use the `podman_registry_username` and `podman_registry_password` variables. Therefore, the `podman` RHEL system role now accepts the `containers-auth.json` file to authenticate against container image registries. For that purpose, you can use the following role variable: `podman_credential_files` (list of dictionary elements):: Each dictionary element in the list defines a file with user credentials for authentication to private container image registries. For security, encrypt these credentials using the Ansible Vault feature. You can specify file name, mode, owner, group of the file, and can specify the contents in different ways. See the role documentation for more details. As a result, you can input container image registry credentials for automated and unattended operations. For more details, see the resources in the `/usr/share/doc/rhel-system-roles/podman/` directory. Alternatively, you can review the `containers-auth.json(5)` and `containers-registries.conf(5)` manual pages.
    • Done
    • None

      The role currently allows you to configure credential-helpers in registries.conf, but it does not provide a way to specify an auth.json file or other credential source. The only way to provide credentials currently is via the undocumented and misnamed 'container_image_user' and 'container_image_password' parameters, which are global - there is no way to specify different credentials for different registries or images. The role should support passing in one or more containers-auth.json files, and check that if the user specifies 'credential-helpers' in registries.conf, those files are specified in 'podman_credential_files'. We should ensure that the auth.json can be specified encrypted with Ansible vault, and that should be tested. Note that setting credential-helpers to 'containers-auth.json' is a special, reserved value which has special handling - see man containers-auth.json for more information. The role should honor that setting and behave as described in the man page.

      New parameter - podman_credential_files - this is a list of credential file items.

      podman_credential_files:
        - file_src: my_auth.json
          file: auth.json
          user: $username
          mode: "0600"
      

      will copy the file my_auth.json (looked up in the default ansible file lookup path) to the remote system /home/$username/.config/containers/auth.json.

      • file_src - source to copy to the remote system - if not an absolute path, will be found using the usual ansible file lookup path (e.g. files/)
      • template_src - source to template then copy - uses the ansible template: module
      • file_content - you can provide the contents inline (e.g. like the content parameter of the copy module) - but use file_src and template_src for large or complex files
      • file - the destination on the source - if not absolute path, then use the default directory ~/.config/containers for root and rootless. If file is not specified, use ~/.config/containers/auth.json for root and rootless.
      • user - user directory for ~/.config and the owner of the file. If 'user' is not specified, then use the podman_run_as_user setting.
      • mode - file mode - defaults to "0600"

      The file_src, template_src, file_content, and file parameters behave just like they do in https://github.com/linux-system-roles/podman/?tab=readme-ov-file#podman_quadlet_specs

      Security

      We should use no_log: true for any tasks which could potentially expose the contents of these files.
      We should ensure that all files containing secrets, or secret values, can be passed via Ansible Vault encrypted values/files.

      Acceptance Criteria

      • User can specify 'podman_credential_files' with the above parameters and behavior
      • 'podman_credential_files' is documented in the README.md
      • There are tests in tests/ for the above which use Ansible Vault encrypted files/values
      • Confirm that no credentials values are logged

      spetros@redhat.com rhn-support-briasmit nkinder@redhat.com vrothber@redhat.com

              rmeggins@redhat.com Richard Megginson
              rmeggins@redhat.com Richard Megginson
              Richard Megginson Richard Megginson
              David Jez David Jez
              Jaroslav Klech Jaroslav Klech
              Votes:
              0 Vote for this issue
              Watchers:
              11 Start watching this issue

                Created:
                Updated:
                Resolved: