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

Unification of dex config into `.spec.sso`, and creation of pods when enabled

    XMLWordPrintable

Details

    • GITOPS Sprint 210, GITOPS Sprint 211, GITOPS Sprint 218, GITOPS Sprint 219, GITOPS Sprint 220

    Description

      Upstream issue
      https://github.com/argoproj-labs/argocd-operator/issues/653

      Description
      As an Argo CD admin/user I would like to see all the SSO provider under `.spec.sso` field in the Argo CD CR. Moving to this "provider" parameter will allow at most one SSO provider to be enabled at any time. We can then enforce Dex pods should only be created when `.spec.sso.provider: dex` is enabled

      Background:
      1. Currently Keycloak SSO provider can be configured using the `.spec.sso.provider` option whereas Dex can be configured using the `.spec.dex` field in the Argo CD CR. The goal is to have a unified location for all the SSO providers.
      2. Currently Dex pods are created by default for any Argo CD instance created by the gitops-operator unless the DISABLE_DEX env var is set to `true` in the CSV/Subscription resource. This behavior should be changed. Dex pods should only be created when `.spec.sso.provider: dex` is configured in the Argo CD CR.

      We want to migrate the dex configurations from `.spec.dex` to `.spec.sso.dex` within the Argo CD CR. However, removing `.spec.dex` would be a breaking change, and as such, should not be done immediately. We should instead add the option of configuring `.spec.sso.dex` into the Argo CD CR alongside `.spec.dex` for backward compatibility. The operator should be equipped to handle both configurations (until GitOps v1.9 when `.spec.dex` will be deprecated and support will be removed from the operator`) Similarly, we should also continue supporting DISABLE_DEX during this time (as the experience would be inconsistent if we didn't) and remove support for it along with `.spec.dex`

      This story is about updating the operator's reconciliation logic to react to changes made to both `.spec.dex` and `.spec.sso.dex` 

      Acceptance Criteria:
      1. `.spec.dex` is deprecated and a notice is added to release notes that it will be removed in v1.9

      2. `DISABLE_DEX` is deprecated and a notice is added to release notes that it will be removed in v1.9
      3. A k8s event is created when `.spec.dex` or DISABLE_DEX is used by customer (Slack convo)
      4. `.spec.sso` is added as the right way of specifying sso provider and added to the release notes
      5.  The operator logic is updated to handle both old and new configuration for SSO simultaneously, and all edge cases are handled 

      Attachments

        Issue Links

          Activity

            People

              jrao@redhat.com Jaideep Rao
              aveerama@redhat.com Abhishek Veeramalla
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: