As a user of OpenShift GitOps, I want to make sure that all communication between the Argo CD components and Redis cache are properly secured using modern TLS encryption, so that possibly sensitive data moving from and to the cache is protected from eavedroppers in transit.

Notes:

As of version 2.1, Argo CD's Redis client can be configured to connect to Redis using TLS via the following command line flags to argocd-server, argocd-repo-server and argocd-application-controller:

      --redis-ca-certificate string                   Path to Redis server CA certificate (e.g. /etc/certs/redis/ca.crt). If not specified, system trusted CAs will be used for server certificate validation.
      --redis-client-certificate string               Path to Redis client certificate (e.g. /etc/certs/redis/client.crt).
      --redis-client-key string                       Path to Redis client key (e.g. /etc/certs/redis/client.crt).
      --redis-insecure-skip-tls-verify                Skip Redis server certificate validation.
      --redis-use-tls                                 Use TLS when connecting to Redis. 

Acceptance Criteria

• The Argo CD components (argocd-server, argocd-repo-server as well as argocd-application-controller) need to be able to (optionally) communicate   to Redis using TLS.

• The user can either bring their own key/certificate pair, or leverage the OpenShift service CA to issue an appropriate certificate, similar to how TLS is  implemented for argocd-repo-server already ("autoTLS" feature).  This should be reflected in the spec, e.g:
    

  spec:
    redis:
      autoTLS: openshift

• The TLS key/certificate pair is to be stored in a Kubernetes secret of type tls, to conform with current Kubernetes standards.

• If this secret exists, Redis should be configured to use the key pair from that secret and the Argo CD components (argocd-server, argocd-repo-server  and argocd-application-controller) must be reconfigured to use TLS connections to the argocd-redis component. In order to be able to verify the TLS connection, possibly the public part of the key pair needs to be mounted to the component's pods and the file containing the public cert can then be used as argument for --redis-ca-certificate parameter.

• Similar to TLS for repo server, the "autoTLS" should be enabled on the non-empty string, and the value should reflect the mechanism to use (for this story, only "openshift" is considered to reflect usage of the OpenShift Service CA issuer).

• If the keypair in the secret is changed (e.g. renewed/rolled over or replaced), the Redis should be made aware of this change and use the new keypair for its TLS endpoint. This has also to be reflected in the clients, when they use the public part of the certificate as verification token.

• The components by default must verify the TLS certificate used by the argocd-redis component, as to establish a secure TLS connection. The user should be able to specify to skip verification of the remote TLS certificate as an opt-in mechanism (e.g. "verifyTLS" set to false)

• We do not need to worry about client cert verification (e.g. mTLS) for now. This user story is about securing data in transit, not authenticating the  client.