Skip to main content

GitOps with control planes

Business Critical Plan Feature

This is a Business Critical Plan feature. For more information, see our pricing plans or contact our sales team.

GitOps is an approach for managing a system by declaratively describing desired resources' configurations in Git and using controllers to realize the desired state. Upbound's control planes are compatible with this pattern and it's strongly recommended you integrate GitOps in the platforms you build on Upbound.

Integrate with Argo CD​

Argo CD is a project in the Kubernetes ecosystem commonly used for GitOps. You can use it in tandem with Upbound control planes to achieve GitOps flows. The sections below explain how to integrate these tools with Upbound.

Configure connection secrets for control planes​

You can configure control planes to write their connection details to a secret. Do this by setting the spec.writeConnectionSecretToRef field in a control plane manifest. For example:

apiVersion: spaces.upbound.io/v1beta1
kind: ControlPlane
metadata:
  name: ctp1
  namespace: default
spec:
  writeConnectionSecretToRef:
    name: kubeconfig-ctp1
    namespace: default

Configure Argo CD​

To configure Argo CD for Annotation resource tracking, edit the Argo CD ConfigMap in the Argo CD namespace. Add application.resourceTrackingMethod: annotation to the data section as below.

Next, configure the auto respect RBAC for the Argo CD controller. By default, Argo CD attempts to discover some Kubernetes resource types that don't exist in a control plane. You must configure Argo CD to respect the cluster's RBAC rules so that Argo CD can sync. Add resource.respectRBAC: normal to the data section as below.

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-cm
data:
  ...
  application.resourceTrackingMethod: annotation
  resource.respectRBAC: normal
tip

The resource.respectRBAC configuration above tells Argo to respect RBAC for all cluster contexts. If you're using an Argo CD instance to manage more than only control planes, you should consider changing the clusters string match for the configuration to apply only to control planes. For example, if every control plane context name followed the convention of being named controlplane-<name>, you could set the string match to be controlplane-*

Create a cluster context definition​

Once the control plane is ready, extract the following values from the secret containing the kubeconfig:

kubeconfig_content=$(kubectl get secrets kubeconfig-ctp1 -n default -o jsonpath='{.data.kubeconfig}' | base64 -d)
server=$(echo "$kubeconfig_content" | grep 'server:' | awk '{print $2}')
bearer_token=$(echo "$kubeconfig_content" | grep 'token:' | awk '{print $2}')
ca_data=$(echo "$kubeconfig_content" | grep 'certificate-authority-data:' | awk '{print $2}')

Generate a new secret in the cluster where you installed Argo, using the prior values extracted:

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Secret
metadata:
  name: ctp-secret
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: cluster
type: Opaque
stringData:
  name: ctp
  server: $server
  config: |
    {
      "bearerToken": "$bearer_token",
      "tlsClientConfig": {
        "insecure": false,
        "caData": "$ca_data"
      }
    }
EOF