Uploaded image for project: 'OpenShift GitOps'
  1. OpenShift GitOps
  2. GITOPS-5903

Include upstream annotation hiding in the operator

XMLWordPrintable

    • Add UI annotation hiding
    • False
    • None
    • False
    • In Progress
    • 0% To Do, 0% In Progress, 100% Done
    • Hide
      With this update, users can hide specific annotations on Secret resources from the ArgoCD UI and CLI. A new resource.sensitive.mask.annotations key has been introduced, which accepts a comma-separated list of metadata.annotations keys whose values will be masked in the UI and CLI.

      This feature is particularly useful for masking sensitive data stored in annotations on Secret resources. Please refer to the [documentation](Add link) for more details
      Show
      With this update, users can hide specific annotations on Secret resources from the ArgoCD UI and CLI. A new resource.sensitive.mask.annotations key has been introduced, which accepts a comma-separated list of metadata.annotations keys whose values will be masked in the UI and CLI. This feature is particularly useful for masking sensitive data stored in annotations on Secret resources. Please refer to the [documentation](Add link) for more details

      The ability to hide annotations from the Argo CD web UI has been added to the upstream. This epic is for bringing this capability into the operator. 

      Why is this important?

      Requested by a customer in RFE-5414, and this feature is an important one for security.

      Scenarios

      1. From the RFE:

      A gitops project that is synchronizing resource definitions that imply secret creation are showing these secrets in the project.

      If one of these secrets is of type "kubernetes.io/dockercfg", while the content is obfuscated, the annotations are not.

      Any secret of type "kubernetes.io/dockercfg" has the annotation "openshift.io/token-secret.value" with the token in clear that can be seen by the administrator of the gitops project and the token could be used to have access to unwanted resources.

      Acceptance Criteria (Mandatory)

      • CI - MUST be running successfully with tests automated
      • Release Technical Enablement - Provide necessary release enablement details and documents.
      • Specified annotations are not displayed in the UI
      • Feature is added to the release notes

      Dependencies (internal and external)

      None known.

      Open questions:

      None known.

      Done Checklist

      • Acceptance criteria are met
      • Non-functional properties of the Feature have been validated (such as performance, resource, UX, security or privacy aspects)
      • User Journey automation is delivered
      • Support and SRE teams are provided with enough skills to support the feature in production environment

              rh-ee-sghadi Siddhesh Ghadi
              halawren@redhat.com Harriet Lawrence
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated:
                Resolved: