cub cluster svc-account-bootstrap

Create a cluster's service account and put its credentials in the cluster

Synopsis

The second part of "cub cluster attach", on its own, for a cluster "cub cluster controller-install" set up. "cub cluster attach " finishes the job later, picking the cluster up where this left it.

In ConfigHub it creates the cluster's identity, a service account with no organization role named argo-, and grants its user View, Edit, ViewChildren and EditChildren on the cluster's OCI target: what the controller needs to pull the Releases of every Space that releases to the target, and argobot to find the target, store the cluster's facts on it and record each Release's live status. Claim on argobot's Channel is granted where the Channel is created, when argobot is installed.

In the cluster it puts the service account's credentials:

a private key in the argobot-secrets Secret in the argobot namespace, which argobot authenticates with. Skipped with --no-k8sbot, for a cluster that will not run argobot; installing argobot later issues one. a pull token a token that does not expire, as the controller's registry credentials: Argo CD's confighub-oci-creds repo-creds Secret, Sveltos's confighub-gateway Secret, or Flux's confighub-oci Secret.

Neither credential is kept anywhere else: ConfigHub holds the public half of the key and a revocable record of the token.

A cluster that takes credentials only from a secret store, through the External Secrets Operator, gets them with --secrets-dir

: each Secret's Kubernetes manifest, exactly what would be applied, is written to //_.yaml instead of being applied. The values are in plain text, in the manifest's stringData, so the file is readable only by you; argobot's also holds the argobot Namespace, which is applied. Load the values into the store, and have the store keep a Secret of that name in the cluster with the manifest's type, labels, annotations and keys. The controller cannot pull, nor argobot start, until it is there. Pass the same --secrets-dir to "cub cluster attach", which then installs argobot with the key in the file rather than issuing another. The key and the token belong to the cluster's service account, which this creates, so they cannot be put in the store before it runs. The Secrets Store CSI driver's secretObjects keeps a Secret only while a pod mounts its volume, which argobot and the controller do not; see "cub cluster attach --help".

"cub cluster detach --delete-config" undoes this with the rest of the cluster's wiring.

Examples: cub cluster create lab cub cluster controller-install lab --provider kind cub cluster svc-account-bootstrap lab cub cluster attach lab

cub cluster svc-account-bootstrap <name> [flags]

Options

  -h, --help                 help for svc-account-bootstrap
      --no-k8sbot            skip argobot's private key, for a cluster that will not run argobot (installing argobot later issues one)
      --secrets-dir string   write the Secrets holding ConfigHub credentials (argobot's key, the controller's pull token) to this directory as Kubernetes Secret manifests instead of applying them, for a secret store, such as the External Secrets Operator, to put in the cluster

Options inherited from parent commands

      --context string   The context to use for this command
      --debug            Debug output

cub cluster svc-account-bootstrap