Strongly-typed API for Repository Configuration

[sbose78]

Summary

Given that Git repositories are the center of the ArgoCD/GitOps/CD world, the configuration for the same deserves a strongly-typed API to avoid error-prone handing of configuration. Could we introduce a new CRD for making it easy for admins/operators to add/remove "valid" repository configurations without having to touch a large configmap ?

This proposal aims to do the following:

• Decouple declaration of repositories from the main configuration argocd-cm.yaml.
• Provide a Kubernetes-native way of managing Git Repository configuration.
• Provide a kubernetes-native way of enforcing structural schema validation ( OpenAPI validation schema ) in the CLI/UI. kubectl, and we are good - no new validation tooling needed!
• Have the associated UI be driven entirely off the OpenAPI validation schema.
• If possible, use the same API across other Argo projects too.

Motivation

Please give examples of your use case, e.g. when would you use this.

As an operator, I wish to manage repository configuration for a large number of repos. I wish to look up the configured repositories by doing a

kubectl get gitrepositoryconfigs

I wish to remove a specific repo configuration by doing a `

kubectl delete gitrepositoryconfig my-old-repo

I wish to add a new repo configuration by doing a

kubectl create -f gitrepositoryconfig.yaml

The GitRepositoryConfig CR

apiVersion: argoproj.io/v1alpha1
kind: GitRepositoryConfig
metadata:
  name: hello-world
  namespace: argocd-namespace
spec:
  url: https://github.com/argoproj/my-private-repository
  sshAuthCredentials: 
      name: hello-world-credentials
status:
   registered: <condition status> 
  

An admission webhook or controller would validate:

• If the former, validate the structure of the CR and based on the type of credentials, validate the content of the secret before 'admission'
• If the latter, validate the structure of the CR and based on the type of credentials, validate the content of the secret, and record results in .status.registered.

Credentials for hello-world GitRepositoryConfig

apiVersion: v1
kind: Secret
metadata:
  name: hello-world-credentials
  namespace: argocd-namespace
  annotations:
type: kubernetes.io/ssh-auth
stringData:
  ssh-privatekey: <private-key> # well-known secret key
  known_hosts: <known-hosts> # well-known secret key

Optionally use basicAuth

apiVersion: v1
kind: Secret
metadata:
  name: hello-world-credentials-basic
  namespace: argocd-namespace
  annotations:
type: kubernetes.io/basic-auth
stringData:
  username: <cleartext username> # well-known secret key
  password: <cleartext password> # well-known secret key

How do you think this should be implemented?

The Golang API equivalent to the GitRepositoryConfig CRD would look like this:

     // GitRepositoryConfig contains the source repo configuration metadata
    type GitRepositoryConfig struct {

        // URL of the git repo
        URL string `json:"url"`

        // BasicAuthCredentials refers to the secret that contains basic auth credentials to access the git repo. Optional.
        BasicAuthCredentials *corev1.LocalObjectReference `json:"basicAuthCredentials,omitempty"`

        // SSHAuthCredentials refers to the secret that contains SSH credentials to access the git repo. Optional.
        SSHAuthCredentials *corev1.LocalObjectReference `json:"sshAuthCredentials,omitempty"`
    
    }

• Instead of watching for repository configuration in the argocd-cm.yaml, the relevant controller would watch for GitRepositoryConfig CRs.
• Resources ( GitRepositoryConfig CRD, associated secrets ) would be watched only in the namespace where ArgoCD is installed. Although, we may consider watching GitRepositoryConfig as part of a separate discussion.
• A GitRepositoryConfig CR may be validated in the reconcile loop and the validation result may be written into the CR's .status, OR
• A GitRepositoryConfig CR may be validated using an admission webhook.
• For the sake of backward compatibility, repository configuration in argocd-cm.yaml would be honored too.

[jangraefen]

Hey @sbose78,

have you seen the discussion in #5436? The possibility of a CRD was also briefly touched there. Maybe you can weight in on that discussion?

[sbose78]

Thank you @jangraefen !