Epic Goal

The main goal of this Epic is to research, design, and submit a Design Proposal Document to the Argo CD community for a new feature. This feature will let cluster administrators define rules to hide (mask/scrub) sensitive values in non-Secret Kubernetes resource fields, ensuring they are not exposed in the Argo CD UI or CLI.

Why is this important?

Argo CD currently redacts values on data and stringData within Secret resources. It also supports redacting annotations on Secret resources by specifying keys in resource.sensitive.mask.annotations in argocd-cm.

However, there are other Custom Resources (CRs) such as OpenShift Routes, third-party certificate management CRDs, or database operator CRs, that store sensitive data in their .spec or other fields. Since Argo CD is unaware of these custom sensitive fields, it displays them as is in the UI/CLI, creating a significant security and compliance risk.

Scenarios

As an administrator, I want to ensure sensitive TLS data stored in fields like .spec.tls.certificate and .spec.tls.key within an OpenShift Route Resource is not exposed in the Argo CD UI/CLI. I can configure the Route TLS fields to be masked in the argocd-cm so that Argo CD will scrub this value before displaying it.

This feature will benefit other objects as well which store sensitive data outside of a Kubernetes Secret.

Other Considerations

• The goal of this Epic is to create and present a Design Proposal Document to the community for feedback and acceptance. The implementation of the accepted design will be addressed in a separate, subsequent Epic.

• The redaction logic must be applied at the API layer within Argo CD. This means the code changes will primarily target the core gitops-engine, which is responsible for reading and processing resource data from the cluster/Redis. Sensitive fields must be scrubbed before the data is exposed to the UI or CLI clients.

• The design of the new configuration can be modeled after the existing resource exclusion feature. For example:

  data:
    # Proposed new key to mask specific fields
    resource.sensitive.mask: |
      - apiGroups:
          - "route.openshift.io/v1"
        kinds:
          - Route
        fields:
          - spec.tls.key
          - spec.tls.certificate 

• The existing annotation masking feature can also be used for design inspiration. GITOPS-4445 

Definition of Ready

• The epic has been broken down into stories.
• Stories have been scoped.
• The epic has been stack ranked.

Definition of Done

• Code Complete:
  • All code has been written, reviewed, and approved.
• Tested:
  • Unit tests have been written and passed.
  • Integration tests have been completed.
  • System tests have been conducted, and all critical bugs have been fixed.
  • Tested on OpenShift either upstream or downstream on a local build.
• Documentation:
  • User documentation or release notes have been written.
• Build:
  • Code has been successfully built and integrated into the main repository / project.
• Review:
  • Code has been peer-reviewed and meets coding standards.
  • All acceptance criteria defined in the user story have been met.
  • Tested by reviewer on OpenShift.
• Deployment:
  • The feature has been deployed on OpenShift cluster for testing.
• Acceptance:
  • Product Manager or stakeholder has reviewed and accepted the work.