ArgoCD Skill

ArgoCD Skill

This skill allows the agent to interact with ArgoCD using the argocd CLI tool, as well as create Declarative GitOps configurations.

Tool Setup

The argocd CLI might need to be downloaded if not present. Run the installation script:

bash skills/argo-cd/scripts/install-cli.sh
sudo mv argocd /usr/local/bin/

Or you can use Homebrew on macOS:

brew install argocd

Basic CLI Commands

• Login: argocd login <SERVER> (Needs initial password argocd admin initial-password -n argocd or other configuration)
• List apps: argocd app list
• Get app status: argocd app get <app-name>
• Sync an app: argocd app sync <app-name>
• Create app (CLI): argocd app create <name> --repo <repo> --path <path> --dest-server <server> --dest-namespace <namespace>
• Create project: argocd proj create <project-name> -d <server>,<namespace> -s <repo>

Declarative Setup

ArgoCD configurations are often applied as Custom Resources (CRs) using kubectl apply.

Application Definition

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

Tool support: Kustomize

When the source path has a kustomization.yaml, ArgoCD detects it as a Kustomize application. You can specify a custom kustomize version, or parameters in the Application spec:

  source:
    path: kustomize-guestbook
    repoURL: https://github.com/argoproj/argocd-example-apps.git
    targetRevision: master
    kustomize:
      version: v4.4.0
      patches:
        - target:
            kind: Deployment
            name: guestbook-ui
          patch: |-
            - op: replace
              path: /spec/template/spec/containers/0/ports/0/containerPort
              value: 443

Tool support: Helm

Helm charts can be passed parameters via helm.parameters or helm.values.

  source:
    repoURL: 'https://charts.helm.sh/stable'
    targetRevision: '1.2.3'
    chart: 'my-chart'
    helm:
      parameters:
      - name: "service.type"
        value: "LoadBalancer"
      values: |
        ingress:
          enabled: true

Tool support: OCI

Helm charts can also be pulled from OCI registries (e.g. Amazon ECR, Google GCR, Docker Hub).

  source:
    repoURL: registry-1.docker.io/bitnamicharts
    targetRevision: 12.0.2
    chart: nginx
    helm:
      values: |
        ingress:
          enabled: true

Projects & RBAC

ArgoCD Projects logically group applications. By default, applications use the default project. Projects can restrict allowed source repos, destination clusters, and kinds of resources.

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: my-project
  namespace: argocd
spec:
  description: Example Project
  sourceRepos:
  - "https://github.com/my-org/*"
  destinations:
  - namespace: my-namespace
    server: https://kubernetes.default.svc
  clusterResourceWhitelist:
  - group: '*'
    kind: '*'

Private Repositories

If the Git repository is private, credentials must be added to ArgoCD, often as a Secret:

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

For project scoped repositories, add project: <project-name> to stringData.

Auditing Projects

As a skill, you can use ArgoCD to audit projects. When requested to audit a project, evaluate the following:

• Source Repositories (sourceRepos): Are there unexpected or overly permissive wildcards allowing unknown code origins? E.g., * vs https://github.com/my-org/*.
• Destinations (destinations): Where is the project permitted to deploy? Are kube-system or root cluster targets appropriately restricted?
• Resource Kinds: Are cluster-scoped resources (clusterResourceWhitelist or clusterResourceBlacklist) restricted appropriately? E.g., is the project allowed to create new Namespaces or CRDs unchecked?
• Roles & RBAC: Are roles defined using least privilege? Examine defined roles to ensure policies don't grant broader access than necessary (e.g., granting * on applications unless intended).