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 the worker listed on it, and to anyone with ViewChildren permission on it. 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 needs no worker. With none named it defaults to ProviderType OCI and ToolchainType Any, which is what a pull destination is. 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, not through a worker.

A Worker can be named on a Target (cub target create ... cluster '' platform-dev/my-worker). The Target's provider and toolchain are then validated against what the worker supports, and the worker's identity is given ViewChildren permission on the Target, the same access an explicit grant would give. Either way, a GitOps operator such as Argo CD authenticates as a server worker and can pull the Releases published for any Target that worker has permission to view; see integrating with GitOps operators.

Targets are created in a Space but may be attached to Units in any Space. 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.

Provider Type

ProviderType is the delivery mechanism for a Target. In practice you want OCI: the Target's Releases are served from ConfigHub's OCI endpoint for a GitOps operator to pull.

Each Target also has one or more ConfigTypes — a (ProviderType, ToolchainType, LiveStateType) tuple. The first is inlined into the Target as its top-level ProviderType, ToolchainType, and LiveStateType fields; any others appear in the ConfigTypes array. A Unit's ProviderType and ToolchainType are validated against that combined set when the Unit is attached.

You can inspect a Target's ConfigTypes with:

cub target get --space <space> <target-slug> -o jq=".Target"

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.