The operator-argo module: usage examples

Enabling the module

Before you start using the operator-argo module in your Kubernetes cluster, it needs to be enabled. This can be done in one of the ways described below.

Method 1: Enabling using ModuleConfig

Create a ModuleConfig resource to enable the module:

apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: operator-argo
spec:
  enabled: true

Method 2: Enabling using deckhouse-controller

To enable the module, run the following command:

kubectl -n d8-system exec deploy/deckhouse -c deckhouse -it -- deckhouse-controller module enable operator-argo

Disabling the module

Disabling the module will remove the ArgoCD operator (all resources from the namespace d8-operator-argo). However, deployed ArgoCD installations and applications will remain untouched.

If you need to disable the operator-argo module, you can do so using one of the methods described below.

Method 1: Disabling using ModuleConfig

Disable the module by setting the enabled value to false in the ModuleConfig:

apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: operator-argo
spec:
  enabled: false

Method 2: Disabling using deckhouse-controller

To disable the module, run the following command:

kubectl -n d8-system exec deploy/deckhouse -c deckhouse -it -- deckhouse-controller module disable operator-argo

Installing ArgoCD and deploying an ArgoCD application

Deploy ArgoCD, which will be accessible via Ingress. Create the necessary resources using the following manifest:

---
apiVersion: v1
kind: Namespace
metadata:
  name: argocd
---
apiVersion: argoproj.io/v1beta1
kind: ArgoCD
metadata:
  name: argocd
  namespace: argocd
spec:
  server:
    host: <argocd-domain>
    ingress:
      enabled: true
      ingressClassName: <ingressClassName>
      tls:
      - hosts:
        - <argocd-domain>
        secretName: argocd-ingress-tls
    # To avoid internal redirection loops from HTTP to HTTPS, the API server should be run with TLS disabled.
    # https://argo-cd.readthedocs.io/en/stable/operator-manual/ingress/#disable-internal-tls
    insecure: true
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: argocd-ingress
  namespace: argocd
spec:
  dnsNames:
  - <argocd-domain>
  issuerRef:
    kind: ClusterIssuer
    name: letsencrypt
  secretName: argocd-ingress-tls

Create a namespace for your future application. This will provide isolation and management for your application’s resources:

apiVersion: v1
kind: Namespace
metadata:
  name: demo
  labels:
    argocd.argoproj.io/managed-by: argocd

Deploy an ArgoCD application by specifying where your application is located and how to deploy it. Use the following manifest to create the application:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: demo
  namespace: argocd
spec:
  destination:
    namespace: demo
    server: https://kubernetes.default.svc
  project: default
  source:
    path: helm-guestbook
    repoURL: https://github.com/argoproj/argocd-example-apps
    targetRevision: HEAD
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

High availability ArgoCD

Enable HA by setting spec.ha.enabled: true in the ArgoCD CR.

apiVersion: argoproj.io/v1beta1
kind: ArgoCD
metadata:
  name: argocd
  namespace: argocd
spec:
  ha:
    enabled: true
    resources:
      requests:
        cpu: "500m"
        memory: "512Mi"
      limits:
        cpu: "1"
        memory: "1Gi"

NOTE:

HA mode in ArgoCD provides high availability for Redis (state storage) using HAProxy and does not imply automatic high availability for all ArgoCD components.

The HA installation will require at least three different nodes due to pod anti-affinity roles in the specs. Additionally, IPv6 only clusters are not supported.

When ha is enabled, changes to .spec.redis.resources doesn’t have any effect. Redis resource limits can be set using .spec.ha.resources.

Authentication

Using Deckhouse Kubernetes Platform single sign-on system for authentication in ArgoCD

Create an OAuth2 client that will be used for authentication in ArgoCD:

apiVersion: deckhouse.io/v1
kind: DexClient
metadata:
  name: argocd
  namespace: argocd
spec:
  redirectURIs:
    - https://<argocd-domain>/api/dex/callback
    - https://<argocd-domain>/api/dex/callback-reserve

After creating DexClient resource, DKP will register a client with the client ID (clientID) dex-client-argocd@argocd(dex-client-<name>@<namespace>).

Wait for Deckhouse Kunernetes Platform to create a Secret with the client secret:

kubectl -n argocd get secret/dex-client-argocd

Configure ArgoCD to use the DKP single sign-on system:

apiVersion: argoproj.io/v1beta1
kind: ArgoCD
metadata:
  name: argocd
  namespace: argocd
spec:
  sso:
    dex:
      config: |
        connectors:
          - type: oidc
            id: deckhouse
            name: deckhouse
            config:
              issuer: "https://dex.<cluster-domain>/"
              clientID: "dex-client-argocd@argocd"
              clientSecret: "$dex-client-argocd:clientSecret"
              insecureEnableGroups: true
              scopes:
               - profile
               - email
               - openid
               - groups
    provider: dex
  server:
    host: <argocd-domain>
    ingress:
      enabled: true
      tls:
        - hosts:
            - <argocd-domain>
          secretName: argocd-ingress-tls
    # To avoid internal redirection loops from HTTP to HTTPS, the API server should be run with TLS disabled.
    # https://argo-cd.readthedocs.io/en/stable/operator-manual/ingress/#disable-internal-tls
    insecure: true

Restart the ArgoCD server:

kubectl -n argocd rollout restart deploy/argocd-server

If you don’t restart the server, login attempts will fail, and you will see an error in the ArgoCD server log (issue).

An example of the error message...

time="2024-10-16T14:12:59Z" level=warning msg="Failed to verify token: failed to verify token: token verification failed for all audiences: error for aud "argo-cd": Failed to query provider "https://argocd./api/dex": Get "https://argocd./api/dex/.well-known/openid-configuration": tls: failed to verify certificate: x509: certificate is valid for ingress.local, not argocd., error for aud "argo-cd-cli": Failed to query provider "https://argocd./api/dex": Get "https://argocd./api/dex/.well-known/openid-configuration": tls: failed to verify certificate: x509: certificate is valid for ingress.local, not argocd."

Using a self-signed certificate for Dex

If you are using a self-signed certificate for Dex, you need to add the root certificate to the OIDC connector configuration in ArgoCD. Use the rootCAs parameter for this:

apiVersion: argoproj.io/v1beta1
kind: ArgoCD
metadata:
  name: argocd
  namespace: argocd
spec:
  sso:
    dex:
      config: |
        connectors:
          - type: oidc
            id: deckhouse
            name: deckhouse
            config:
              issuer: "https://dex.<cluster-domain>/"
              rootCAs:
                - |
                  -----BEGIN CERTIFICATE-----
                  ... encoded certificate data here ...
                  -----END CERTIFICATE-----
              clientID: "dex-client-argocd@argocd"
              clientSecret: "$dex-client-argocd:clientSecret"
              insecureEnableGroups: true
              scopes:
               - profile
               - email
               - openid
               - groups
    provider: dex
  server:
    host: <argocd-domain>
    ingress:
      enabled: true
      tls:
        - hosts:
            - <argocd-domain>
          secretName: argocd-ingress-tls
    # To avoid internal redirection loops from HTTP to HTTPS, the API server should be run with TLS disabled.
    # https://argo-cd.readthedocs.io/en/stable/operator-manual/ingress/#disable-internal-tls
    insecure: true

To retrieve the Dex certificate from a Kubernetes Secret, use the following command:

kubectl -n <dex-namespace> get secret <dex-tls-secret-name> -o jsonpath='{.data.tls\.crt}' | base64 -d

Place the resulting certificate in PEM format in the rootCAs parameter.

ArgoCD RBAC

Access policies for ArgoCD resources can be applied using the rbac parameter in the configuration file. Below is an example policy that implements the demo-app-viewer role for all applications in the demo project. All rules for creating access policies can be found in the ArgoCD documentation:

apiVersion: argoproj.io/v1beta1
kind: ArgoCD
metadata:
  name: argocd
  namespace: argocd
spec:
  rbac:
    defaultPolicy: role:none
    policy: |
      # 1. Define the 'demo-app-viewer' role and permissions
      # Allow viewing all applications in the demo project
      p, role:demo-app-viewer, applications, get, demo/*, allow
      # Allow viewing logs of the proj-demo application in the project (demo/proj-demo)
      p, role:demo-app-viewer, logs, get, demo/proj-demo, allow
      
      # 2. Bind the 'viewer' group (obtained from DEX) to the 'demo-app-viewer' role
      g, viewer, role:demo-app-viewer
    policyMatcherMode: glob
    scopes: '[groups]'
  sso:
    dex:
      config: |
        connectors:
          - type: oidc
            id: deckhouse
            name: deckhouse
            config:
              issuer: "https://dex.<cluster-domain>/"
              clientID: "dex-client-argocd@argocd"
              clientSecret: "$dex-client-argocd:clientSecret"
              insecureEnableGroups: true
              scopes:
               - profile
               - email
               - openid
               - groups
    provider: dex

ArgoCD authentication without Dex (admin user)

During the initial deployment of ArgoCD, the operator creates a Kubernetes Secret:

Namespace: argocd
Secret: argocd-cluster
Key: admin.password

This secret stores the initial password of the admin user in base64-encoded form.

You can retrieve the initial admin password using the following command:

kubectl -n argocd get secret argocd-cluster \
  -o jsonpath='{.data.admin\.password}' | base64 -d

Creating ArgoCD Local Users

To create local users in ArgoCD CRD, you need to use the extraConfig parameter:

apiVersion: argoproj.io/v1beta1
kind: ArgoCD
metadata:
  name: argocd
  namespace: argocd
spec:
  extraConfig:
    # Creating a 'deploy' user with token generation and UI login rights
    accounts.deploy: apiKey, login
    # Explicitly enabling the user (default value is true)
    accounts.deploy.enabled: "true"

    # Creating a 'ci-bot' user ONLY for automation (without UI access)
    accounts.ci-bot: apiKey

After defining the user in the ArgoCD CRD manifest, you need to generate a password for UI access, if the corresponding rights (login) are specified.

To create a password via Secret, it must be hashed using bcrypt, and then the result must be encoded in Base64 format:

echo "Flant54321" | htpasswd -BinC 10 "" | cut -d: -f2 | base64 -w0
kubectl patch secret argocd-secret -n argocd -p '{"data":{"accounts.<account-name>.password":"<bCrypt-to-Base64>"}}'

There is also a possibility to add a password via the argocd-server container CLI:

# Specify temporary location for the config file because /config is read-only
export HOME = /tmp 

# Log in
argocd login localhost:8080 --username admin --password <admin-password> --insecure 

# Set the password for the user
argocd account update-password \
  --account <account> \
  --current-password <admin-password> \
  --new-password <desired-password>

For users with the apiKey rights, a token can be generated from the administrator account via the UI (Settings/Accounts/{Account} Token) or via the argocd-server container CLI:

# Specify temporary location for the config file because /config is read-only
export HOME=/tmp 

# Log in
argocd login localhost:8080 --username admin --password <admin-password> --insecure 

# Generate a token
argocd account generate-token --account <account>

Granting ArgoCD access to cluster-wide resources

To allow ArgoCD to manage cluster-wide resources, specify the clusterConfigNamespaces parameter in the module settings:

apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: operator-argo
spec:
  enabled: true
  settings:
    clusterConfigNamespaces: <list of namespaces of cluster-scoped Argo CD instances>
  version: 1

Using a Custom Cluster Domain Instead of cluster.local

To configure ArgoCD to use a custom cluster FQDN (e.g., prod.local), set the clusterDomain field accordingly:

apiVersion: argoproj.io/v1beta1
kind: ArgoCD
metadata:
  name: argocd
  namespace: argocd
spec:
  ...
  clusterDomain: "prod.local"
  ...

The operator-argo module: usage examples

Enabling the module

Method 1: Enabling using ModuleConfig

Method 2: Enabling using deckhouse-controller

Disabling the module

Method 1: Disabling using ModuleConfig

Method 2: Disabling using deckhouse-controller

Installing ArgoCD and deploying an ArgoCD application

High availability ArgoCD

Authentication

Using Deckhouse Kubernetes Platform single sign-on system for authentication in ArgoCD

Using a self-signed certificate for Dex

ArgoCD RBAC

ArgoCD authentication without Dex (admin user)

Creating ArgoCD Local Users

Granting ArgoCD access to cluster-wide resources

Using a Custom Cluster Domain Instead of cluster.local

An error has occurred

Tell us what you didn’t like.

The operator-argo module: usage examples

Enabling the module

Method 1: Enabling using ModuleConfig

Method 2: Enabling using deckhouse-controller

Disabling the module

Method 1: Disabling using ModuleConfig

Method 2: Disabling using deckhouse-controller

Installing ArgoCD and deploying an ArgoCD application

High availability ArgoCD

Authentication

Using Deckhouse Kubernetes Platform single sign-on system for authentication in ArgoCD

Using a self-signed certificate for Dex

ArgoCD RBAC

ArgoCD authentication without Dex (admin user)

Creating ArgoCD Local Users

Granting ArgoCD access to cluster-wide resources

Using a Custom Cluster Domain Instead of cluster.local

An error has occurred

Tell us what you didn’t like.

Request trial access

Thank you

Error

Request callback

Thank you

Something went wrong

Book your sessions

Thank you

Error

Request demo

Thank you

Error

Get the PCI SSC Compliance Report

Thank you

Error