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

feat: manage TLS cert/key files for registry connections and validate certs

XMLWordPrintable

    • rhel-system-roles-1.78.1-0.1.el9
    • 4
    • rhel-sst-system-roles
    • 3
    • 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 variables in the `podman` RHEL system role: `podman_registry_certificates` and `podman_validate_certs`

      The following two variables have been added to the `podman` RHEL system role:

      * `podman_registry_certificates` (list of dictionary elements): Enables you to manage TLS certificates and keys used to connect to the specified container image registry.

      * `podman_validate_certs` (boolean, defaults to null): Controls whether pulling images from container image registries will validate TLS certificates or not. The default null value means that it is used whatever the default configured by the `containers.podman.podman_image` module is. You can override the `podman_validate_certs` variable on a per-specification basis with the `validate_certs` variable.

      As a result, you can use the `podman` RHEL system role to configure TLS settings for connecting to container image registries.

      For more details, see the resources in the `/usr/share/doc/rhel-system-roles/podman/` directory. Alternatively, you can review the `containers-certs(5)` manual page.
      Show
      .New variables in the `podman` RHEL system role: `podman_registry_certificates` and `podman_validate_certs` The following two variables have been added to the `podman` RHEL system role: * `podman_registry_certificates` (list of dictionary elements): Enables you to manage TLS certificates and keys used to connect to the specified container image registry. * `podman_validate_certs` (boolean, defaults to null): Controls whether pulling images from container image registries will validate TLS certificates or not. The default null value means that it is used whatever the default configured by the `containers.podman.podman_image` module is. You can override the `podman_validate_certs` variable on a per-specification basis with the `validate_certs` variable. As a result, you can use the `podman` RHEL system role to configure TLS settings for connecting to container image registries. For more details, see the resources in the `/usr/share/doc/rhel-system-roles/podman/` directory. Alternatively, you can review the `containers-certs(5)` manual page.
    • Done
    • None

      Feature: Add two new parameters:
      podman_registry_certificates is a list of dict. Each dict specifies the
      certs and keys to use to connect to the specified registry using TLS and
      optionally use certificate authentication. More information can be found
      in the manpage for containers-certs.d.
      podman_validate_certs is a boolean which allows you to require or disable
      TLS certificate checking (i.e. if you do not have a CA cert for
      podman_registry_certificates and you still want to pull images from a TLS
      enabled registry). This corresponds to the parameter "validate_certs"
      of the module containers.podman.podman_image. You can also control
      certificate validation by using podman_registries_conf to configure
      the "insecure" parameter for a registry.

      Reason: Users need to be able to configure the TLS settings for
      connecting to registries.

      Result: Users can connect to registries using TLS and control how
      that works.

      QE: tests_auth_and_security.yml has been extended for this.

              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:
              8 Start watching this issue

                Created:
                Updated:
                Resolved: