Skip to content

Target

A Target is an entity in ConfigHub that represents a place configuration is destined for — typically (for now) a Kubernetes cluster.

A Target is an address, not a connection: a named destination that Units can be attached to, so that ConfigHub knows which configuration belongs to which environment. No credentials for that environment are stored on it, and ConfigHub does not reach into it.

How a Target is used

Configuration reaches a Target by being published, not pushed:

  1. Units are attached to a Target, usually because they live in a Space whose release Target (ReleaseTargetID) is set — a variant created with cub variant create --target gets this automatically.
  2. cub release publish bundles those Units into an immutable Release, served from ConfigHub's OCI endpoint.
  3. A GitOps operator running in the cluster — Argo CD, Flux, or Sveltos — pulls that bundle and reconciles it.

The operator holds the cluster credentials, as it already did. ConfigHub holds none. Pull access to the Releases published for a Target is granted on the Target itself: to anyone with ViewChildren permission on it, which includes the Target's creator. See integrating with GitOps operators for the full setup.

Users with permission to use a Target can attach Units to it, which is how authorization is delegated: a platform team creates the Targets and grants Use permission, and application teams attach their own Units without being able to change the Target itself.

Creating a Target

cub cluster up creates a Target for the cluster it provisions. To create one by hand:

cub target create --space platform-dev cluster

A Target takes nothing but its name: it has no provider or toolchain, and accepts Units of any toolchain. Whoever needs to reach the Target — a person attaching Units, or the GitOps operator that pulls its Releases — gets there through the Target's permissions.

A GitOps operator such as Argo CD authenticates as a service account, which needs View and ViewChildren on the Target: ViewChildren to pull the Releases published for it, View to find it. Grant them when creating the Target, or later with cub target update --permission:

cub target create --space platform-dev cluster \
  --permission View:serviceaccount:argo --permission ViewChildren:serviceaccount:argo

See integrating with GitOps operators. A server Worker created for this before service accounts existed keeps working, with the same two permissions granted to its user.

Targets are created in a Space but may be attached to Units in any Space. Making a Target a Space's release Target, like attaching a Unit to it, requires Use permission on the Target. Note that a Space's release Target must already exist when the Space is created, so the Target generally cannot live in the Space it releases — see Publishing Releases for the recommended layout.

Triggers

Triggers may be attached to Targets via filters that select applicable triggers. This is the recommended way to enforce policies that gate releasing configuration to a particular Target — a validation failure records a Validation Error, which blocks cub release publish until it clears.