Story (Required)

As a Argo CD admin, I would like to configure tls for Argo CD server route using cert data from a kubernetes secret instead of directly embedding the sensitive data into ArgoCD CR. 

Background (Required)

The `tls.key` field contains sensitive data and should not be embedded as plain text in a CR. This is not a good practice from a security point of view as it allows anyone who has view permission to get access to this sensitive information. Refer parent epic for more details.

Out of scope

Deprecating existing way of configuring tls i.e via directly embedding tls data into ArgoCD CR.

Approach (Required)

• Provide an option to reference a kubernetes secret containing certificate data in ArgoCD CR. 

spec:  
  server: 
    route: 
      enabled: true      
      tls: 
        externalCertificate: 
          name: custom-tls-cert
        insecureEdgeTerminationPolicy: Redirect
        termination: reencrypt

• The kubernetes secret referenced, should be of type `kubernetes.io/tls`. Throw error for any other secret type.

Example:

apiVersion: v1
kind: Secret
metadata:
  name: custom-tls-cert
type: kubernetes.io/tls
data:
  tls.crt: <base64-encoded-cert>
  tls.key: <base64-encoded-key>

• {}In case of conflict when tls data is provided using new method i.e secrets and old method i.e direct embedding in ArgoCD CR, tls data from secret should be used.
• Setup watch on secret to update the tls data when changed. 

Acceptance Criteria (Mandatory)

• Cert details should not be exposed in the ArgoCD CR.
• It should be possible to refer a secret containing the TLS cert details from the ArgoCD CR.
• Operator should pick up the TLS cert details directly from the secret that is being referenced.
• Only secrets of type kubernetes.io/tls should be referred, for other secret types, it should report an error.

INVEST Checklist

Dependencies identified

Blockers noted and expected delivery timelines set

Design is implementable

Acceptance criteria agreed upon

Story estimated

Legend

Unknown

Verified

Unsatisfied

Done Checklist

• Code is completed, reviewed, documented and checked in
• Unit and integration test automation have been delivered and running cleanly in continuous integration/staging/canary environment
• Continuous Delivery pipeline(s) is able to proceed with new code included
• Customer facing documentation, API docs etc. are produced/updated, reviewed and published
• Acceptance criteria are met