A GitOps continuous delivery tool for Kubernetes

Nothing but the Truth

Private Repos

Argo CD can interact with private Git repositories, allowing you to manage your applications even if their manifests are stored in a private repository. This interaction is achieved by providing Argo CD with the necessary credentials to access the private repository. To configure repository credentials, you need to create a Secret in the same namespace as the Argo CD API server (Listing 5). Secret should contain the necessary credentials to access the private repository.

Listing 5

Private GitHub Repo Secret

apiVersion: v1
kind: Secret
  name: my-repo-secret
    argocd.argoproj.io/secret-type: repository
type: Opaque
  url: https://github.com/my-org/my-repo.git
  username: my-username
  password: my-password

If your private repository uses SSH keys for authentication, you can provide the SSH private key in the Secret instead of a username and password (Listing 6). The url field specifies the SSH URL of the private repository, and the sshPrivateKey field provides the SSH private key. Once the Secret is created, Argo CD can use the provided credentials to access the private repository and manage your applications.

Listing 6

SSH Private Key in a Secret

apiVersion: v1
kind: Secret
  name: my-repo-secret
    argocd.argoproj.io/secret-type: repository
type: Opaque
  url: git@github.com:my-org/my-repo.git
  sshPrivateKey: |
    -----END RSA PRIVATE KEY-----

Multicluster Management

Argo CD supports multicluster deployments, allowing you to manage applications across multiple Kubernetes clusters. Multicluster deployments are particularly useful for managing large-scale deployments and multitenant environments. For example, you can create Argo CD applications for different clusters (Listing 7).

Listing 7

Apps for Different Clusters

# Cluster 1
argocd app create my-app-cluster1 --repo https://github.com/my-org/my-repo.git --path /path/to/application/manifests --dest-namespace default --dest-server https://cluster1.kubernetes.default.svc --sync-policy automated
# Cluster 2
argocd app create my-app-cluster2 --repo https://github.com/my-org/my-repo.git --path /path/to/application/manifests --dest-namespace default --dest-server https://cluster2.kubernetes.default.svc --sync-policy automated

In this example,




are the API servers for the two clusters.

User Management

User management is a crucial aspect of any system, and Argo CD is no exception. Argo CD provides robust user management capabilities, including integration with various authentication providers. It has a built-in user management system that allows you to create and manage users. By default, Argo CD comes with an admin user, for whom you can change the password:

argocd account update-password --current-password <current-password> --new-password <new-password>

Argo CD supports integration with various authentication providers with Dex, which can authenticate users against a variety of sources, including static users and the LDAP, SAML, and OAuth2 standards. For example, to integrate Argo CD with GitHub for authentication, you can configure Dex in the argocd-cm ConfigMap (Listing 8).

Listing 8

Integrating Argo CD with GitHub

apiVersion: v1
kind: ConfigMap
  name: argocd-cm
  namespace: argocd
  dex.config: |
    - type: github
      id: github
      name: GitHub
        clientID: <github-client-id>
        clientSecret: <github-client-secret>
        redirectURI: <argo-cd-redirect-uri>
        - name: my-org

Replace <github-client-id> and <github-client-secret> with your GitHub OAuth app's client ID and client secret, respectively. Replace <argo-cd-redirect-uri> with the redirect URI for your Argo CD instance. Once you've configured Dex, users can log in to Argo CD with their GitHub credentials.

Argo CD also supports role-based access control (RBAC), allowing you to define what actions users can perform in Argo CD. Listing 9 shows how to define roles and bind them to users or groups.

Listing 9


apiVersion: v1
kind: ConfigMap
  name: argocd-rbac-cm
  namespace: argocd
  policy.csv: |
    p, role:developer, applications, get, my-app/*, allow
    p, role:developer, applications, sync, my-app/*, allow
    g, my-org:developers, role:developer

The role:developer role can get and sync applications in the my-app project. The my-org:developers group from the identity provider is bound to the role:developer role.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Native serverless computing in Kubernetes
    Knative transfers serverless workloads to Kubernetes and provides all the container components you need to build serverless applications and PaaS and FaaS services.
  • Secure and seamless server access
    The powerful Cloudflare Tunnel provides secure and seamless access to servers and applications, making it a convenient alternative to VPN for any modern IT infrastructure.
  • Users speak on Kubernetes in business practice
    Users in corporate and government agencies that have successfully switched to Kubernetes share their positive experiences and the stumbling blocks to be avoided.
  • Secure Kubernetes with Kubescape
    Kubescape checks Kubernetes container setups for security and compliance issues, making life easier for administrators.
  • Nested Kubernetes with Loft
    Kubernetes has limited support for multitenancy, so many admins prefer to build multiple standalone Kubernetes clusters that eat up resources and complicate management. As a solution, Loft launches any number of clusters within the same control plane.
comments powered by Disqus
Subscribe to our ADMIN Newsletters
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs

Support Our Work

ADMIN content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.

Learn More”>


		<div class=