Skip to content

Target

A Target is an entity in ConfigHub that represents a deployment target where configuration can be applied for a specific ToolchainType and ProviderType. It abstracts access to Kubernetes clusters and other services. The Target encompasses the location (e.g., IP address, URL -- aka "coordinates") of the system under management and the credentials to access it. It allows ConfigHub users to manage resources without directly handling credentials. The BridgeHandle is an identifier the bridge implementation uses to select the credentials and coordinates to use for a particular Target.

Each Target is associated with a Worker, either a built-in server worker (ProvidedInfo.IsServerWorker is true) or external worker process, which is responsible for managing access to live resources. The worker advertises its available BridgeHandles and supported ConfigTypes (see below).

External workers obtain access through credentials or assumes a role with appropriate permissions. Once the external Worker process establishes access, it can register systems it can access as Targets in ConfigHub.

Users with permission to use a Target can associate Config Units with it, enabling controlled application of configuration changes. Workers may have access to multiple Targets, potentially of multiple toolchain types and/or provider types.

Triggers may be attached to Targets via filters that select applicable triggers. That is the recommended approach to enforce policies that gate releasing configuration to each Target.

Provider Type

Some toolchains support multiple underlying service providers, which may have different kinds of credentials and different configuration details. For instance, the Kubernetes/YAML ToolchainType has multiple providers, because various tools and storage systems have additional or different credentials and configuration. To a first approximation, you can think of ProviderType as a name for the bridge implementation.

You mainly will use server workers, with ProviderType OCI or ConfigHub. You can create a Target corresponding to each of your Kubernetes clusters with ProviderType OCI, and configure your GitOps Operator, such as ArgoCD or Flux, to pull from ConfigHub's OCI endpoint.

Config Types

A Target supports one or more ConfigTypes. Each ConfigType is a (ProviderType, ToolchainType, LiveStateType) tuple that the Target's Worker can handle, optionally with a list of Options (see below). This lets a single Target serve multiple bridges that provide access to the same underlying system under management.

For backward compatibility, the first ConfigType is inlined into the Target as the top-level ProviderType, ToolchainType, LiveStateType, and Options fields. Any additional ConfigTypes appear in the Target's ConfigTypes array. The full set of valid ConfigTypes for a Target is the inlined one plus any entries in ConfigTypes. A Unit's ProviderType and ToolchainType are validated against this 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"

Bridge Options

Bridge Options are only relevant for Bridges implemented in external workers, which are currently experimental.

Each ConfigType may declare Options — parameters that configure how the bridge behaves for that ConfigType. An option has a name (PascalCase), description, required flag, data type, and optional example. Options are set on the Target (and can be overridden per-Unit via TargetOptions). When a Unit's action dispatches, the bridge receives merged values in the payload.

Example: the ArgoCDRenderer and FluxRenderer bridges expose an IsAuthoritative option.

  • IsAuthoritative=false (default) — the Application / HelmRelease / Kustomization must already exist in the cluster; the bridge only reads rendered manifests. The bridge returns an error if autosync is enabled (ArgoCD) or spec.suspend is not true (Flux), because otherwise the GitOps tool, not ConfigHub, would own the rendered output.
  • IsAuthoritative=true — the bridge creates, updates, and deletes the resource itself. For ArgoCD the bridge also disables autosync automatically; for Flux it sets spec.suspend=true automatically.

Set an option on a Target with cub target update --patch --option IsAuthoritative=true <target-slug>.

The full schema is defined in core/worker/api/bridge_worker_info.go (ConfigType, ConfigTypeSignature, BridgeOption, SupportedConfigType).