examples

Operate the Cost Management App app through its generated CLI and browser surface. Use for "Turn fleet cost findings into governed recommendations, approvals, and receipts.", Variant review, proof gaps, preview, approval scope, and receipt checks. Read-only first; live mutation requires the app commit command to prove real ConfigHub bindings.

Operate the Add-on Manager app through its generated CLI and browser surface. Use for "Install, upgrade, review, and prove platform add-ons through governed ConfigHub delivery paths.", Variant review, proof gaps, preview, approval scope, and receipt checks. Read-only first; live mutation requires the app commit command to prove real ConfigHub bindings.

Inventory and report Kubernetes autoscaling stored in ConfigHub across a fleet with the cub-autoscale CLI — HorizontalPodAutoscalers and KEDA ScaledObjects: each one's scale target, min/max replicas, and whether it is pinned (min == max). Use for "what autoscalers do we have?", "list our HPAs / ScaledObjects", "which workloads are autoscaled?", "per-cluster autoscaler counts", "is autoscaler X pinned?". Not for autoscaling findings/anti-patterns (use autoscale-findings), edits or HPA→KEDA conversion (use autoscale-edit), or live cluster state (use kubectl); analysis is over ConfigHub-managed Units only.

Set Kubernetes autoscaling as config-as-data with the cub-autoscale CLI — edit a HorizontalPodAutoscaler's min/max replicas and cpu/memory targets, convert an HPA to a KEDA ScaledObject, apply reusable autoscaling profiles to one Unit or across a whole selector, and promote changes downstream. Use for "raise the HPA max to 20", "set cpu target to 60%", "convert this HPA to KEDA", "make every prod HPA scale out earlier", "apply the hpa-range profile", "roll the autoscaling change downstream". Dry-run by default; requires --commit --change-desc. Not for read-only checks (use autoscale-audit / autoscale-findings) or enforcement Triggers (use autoscale-guardrails).

Produce severity-ranked Kubernetes autoscaling findings across a ConfigHub fleet with the cub-autoscale CLI. Flags autoscalers that are pinned (min == max, can't scale), workloads with no HPA/ScaledObject, and the cross-resource case where a PodDisruptionBudget's minAvailable blocks all voluntary eviction at the autoscaler's minReplicas. Use for "what autoscaling problems do we have?", "which HPAs can't scale?", "which workloads lack an autoscaler?", "is any PDB blocking scale-down?". Not for the raw autoscaler inventory (use autoscale-audit), fixing autoscaling (use autoscale-edit), or live cluster state (use kubectl); analysis is over ConfigHub-managed Units only.

Install and inspect the autoscaling enforcement pack with the cub-autoscale CLI — an autoscale-policy Space with two Warn=true Triggers: a vet-cel rule that flags any HPA/ScaledObject that is pinned (min == max), and a vet-schemas rule that schema-validates every mutation (the post-convert check for convert-keda output, since keda.sh is in the schema catalog) — wired to in-scope Spaces via a shared Trigger Filter. guardrails install (dry-run by default) and status (Units with ApplyWarnings/Gates). Use for "enforce that no HPA is pinned", "make sure converted ScaledObjects pass schema validation", "which autoscalers are flagged?". Not for read-only findings (use autoscale-findings) or fixing autoscaling (use autoscale-edit).

Inventory the observability posture of Kubernetes workloads stored in ConfigHub across a fleet with the cub-observability CLI — ServiceMonitors, Services (and which expose metrics), and telemetry-sidecar presence. Use for "what ServiceMonitors / Services do we have?", "which Services expose metrics?", "which workloads have an otel sidecar?", "per-cluster observability counts". Not for ServiceMonitor coverage gaps (use observability-findings), fixes (use observability-instrument / observability-guardrails), or live cluster state (use kubectl); analysis is over ConfigHub-managed Units only.

Produce severity-ranked observability findings across a ConfigHub fleet with the cub-observability CLI — a metrics-exposing Service with no ServiceMonitor selecting it (the cross-Unit coverage join), and a dangling ServiceMonitor that selects nothing. Use for "what observability gaps do we have?", "which metrics Services are not scraped?", "any ServiceMonitors selecting nothing?", "observability findings for the checkout component". Not for the raw coverage report (use observability-audit), fixes (use observability-instrument), or live cluster state (use kubectl); analysis is over ConfigHub-managed Units only.

Install and operate the observability enforcement pack with the cub-observability CLI — an observability-policy Space with a Warn=true vet-cel Trigger that flags metrics-exposing Services with no ServiceMonitor, fed by annotate-then-validate (coverage is a cross-Unit property). guardrails install (dry-run by default), status (Units with ApplyWarnings/Gates), annotate (write the coverage finding onto uncovered Service Units). Use for "enforce that metrics services are scraped", "warn on services with no ServiceMonitor", "which services are flagged?". Not for read-only findings (use observability-findings) or fixing coverage (use observability-instrument).

Instrument Kubernetes workloads for observability as config-as-data with the cub-observability CLI — author a Prometheus ServiceMonitor for a Service (ensure-servicemonitor), inject an OpenTelemetry/telemetry sidecar container (inject-sidecar via set-path), one workload or across a selector via profiles. Use for "add a ServiceMonitor for the checkout service", "scrape this service", "inject an otel sidecar into web", "add the otel collector to every prod workload", "roll instrumentation downstream". Dry-run by default; requires --commit --change-desc. Not for read-only checks (use observability-audit / observability-findings), enforcement Triggers (use observability-guardrails), or applying to a cluster.

Inventory and report the placement of Kubernetes workloads stored in ConfigHub across a fleet with the cub-scheduling CLI — where each workload is allowed to land: nodeSelector, tolerations, and node affinity. Use for "where do our workloads schedule?", "which workloads pin to a node pool?", "what does workload X tolerate?", "which workloads are unconstrained?", "per-cluster placement counts". Not for placement anti-pattern findings (use scheduling-findings), fixes (use scheduling-place), pod anti-affinity / topology spread (that is availability, owned by workload-manager), or live cluster state (use kubectl); analysis is over ConfigHub-managed Units only.

Produce severity-ranked Kubernetes workload placement findings across a ConfigHub fleet with the cub-scheduling CLI. v1 flags controllers that tolerate a taint but do not constrain where they land (no nodeSelector and no required node affinity), so they may schedule onto general nodes. Use for "what placement problems do we have?", "which workloads tolerate a taint but do not pin a node pool?", "placement findings for the ml component". Not for the raw placement report (use scheduling-audit), fixing placement (use scheduling-place), or availability spread (use workload-manager); analysis is over ConfigHub-managed Units only.

Install and inspect the placement enforcement pack with the cub-scheduling CLI — a scheduling-policy Space with a Warn=true vet-cel Trigger that flags controllers which tolerate a taint but do not constrain where they land (no nodeSelector or required node affinity), wired to in-scope Spaces via a shared Trigger Filter. guardrails install (dry-run by default) and status (Units with ApplyWarnings/Gates). Use for "enforce that tolerations come with placement", "warn on workloads that tolerate a taint but pin nothing", "which workloads are flagged?". Not for read-only findings (use scheduling-findings) or fixing placement (use scheduling-place).

Set Kubernetes workload placement as config-as-data with the cub-scheduling CLI — nodeSelector, tolerations, and node affinity — one workload or across a whole selector via reusable placement profiles. Use for "pin this workload to the gpu pool", "add a toleration for the spot taint", "put the ml deployments on the gpu nodes", "set node affinity to a zone", "apply the placement-gpu profile", "roll placement downstream". Dry-run by default; requires --commit --change-desc. Not for read-only checks (use scheduling-audit / scheduling-findings), enforcement Triggers (use scheduling-guardrails), or pod anti-affinity / topology spread (that is availability, owned by workload-manager).

Inventory Kubernetes workloads stored in ConfigHub across the fleet and score their production-readiness (security context, resources/limits, probes, operational hygiene) with the cub-workload CLI. Use for "what workloads do we have?", "which workloads run as root / have no limits / no probes?", "what is the readiness of workload X?", "per-cluster workload counts", "score the dev workloads". Not for PodDisruptionBudget coverage / anti-affinity (use workload-availability), ranked findings (use workload-findings), fixes (use workload-harden), or live cluster state (use kubectl); analysis is over ConfigHub-managed Units only.

Report the disruption-survival posture of multi-replica Kubernetes workloads across a ConfigHub fleet with the cub-workload CLI — PodDisruptionBudget coverage (does a matching PDB exist in some other Unit?), the minAvailable>=replicas / maxUnavailable:0 eviction-lock footgun, and pod anti-affinity / topology spread presence. Use for "which multi-replica workloads have no PDB?", "is workload X covered by a PodDisruptionBudget?", "which workloads could lose every replica to one node/zone failure?", "does this workload have anti-affinity?". Not for security/resources/probes scoring (use workload-audit), ranked findings (use workload-findings), or fixes (use workload-harden); analysis is over ConfigHub-managed Units only.

Produce a severity-ranked list of Kubernetes workload-readiness findings across a ConfigHub fleet with the cub-workload CLI, spanning every analyzer (security, resources, probes, hygiene, availability). Use for "what is wrong with our workloads, ranked?", "show the high-severity workload issues", "workload findings for the payments component", "audit workload readiness across the fleet". Not for the raw per-workload scorecard (use workload-audit), PDB-only coverage (use workload-availability), or fixing issues (use workload-harden); analysis is over ConfigHub-managed Units only.

Fleet-scale workload remediation and the reusable profile library with the cub-workload CLI — profile install/list/apply (parameterized Invocations: resource tiers, harden, probes, anti-affinity, termination policy), fleet-edit (apply a profile across a --where selector of workloads in one operation), and promote (override-preserving upgrade of downstream Units to their upstream head). Use for "harden every prod workload", "set medium resources across the checkout component", "apply the anti-affinity profile fleet-wide", "roll the workload fix downstream", "list the workload profiles". Dry-run by default; requires --commit --change-desc. Not for a single-workload fix (use workload-harden), read-only checks (use workload-audit / workload-findings), or enforcement Triggers (use workload-guardrails).

Install and operate the workload-readiness enforcement pack with the cub-workload CLI — a workload-policy Space of Warn=true vet-cel Triggers (containers set a memory limit, run as non-root, set terminationMessagePolicy) plus an annotate-then-validate Trigger for cross-Unit PodDisruptionBudget coverage, wired to in-scope Spaces via a shared Trigger Filter. guardrails install (dry-run by default), status (Units with ApplyWarnings/Gates), annotate (write the PDB-coverage finding onto uncovered workloads). Use for "enforce workload readiness", "block workloads with no memory limit", "warn on workloads with no PDB", "which workloads are flagged?". Not for read-only scoring (use workload-audit / workload-findings) or fixing workloads (use workload-harden / workload-fleet).

Fix a single Kubernetes workload's production-readiness gaps as config-as-data with the cub-workload CLI — harden (security-context + automount defaults), set-resources (requests/limits by tier or explicit), set-probes (liveness/readiness/startup), ensure-pdb (author a PodDisruptionBudget whose selector is derived from the workload), ensure-spread (pod anti-affinity or topology spread). Use for "harden the checkout deployment", "set resources on workload X", "add probes", "add a PDB for this workload", "spread this deployment across nodes", "fix workload X's findings". Dry-run by default; requires --commit --change-desc. Not for read-only checks (use workload-audit / workload-findings), bulk edits across many workloads or the profile library (use workload-fleet), or enforcement Triggers (use workload-guardrails).

Inventory and audit Kubernetes NetworkPolicy coverage stored in ConfigHub across the fleet, using the cub-netpol CLI. Use for "what NetworkPolicies do we have?", "which namespaces have no default-deny?", "which workloads are uncovered?", "per-cluster NetworkPolicy/namespace/workload counts", "list the policies in apptique-prod", "audit our network segmentation". Not for "who can reach X" connectivity (use netpol-connectivity) or hygiene/anti-pattern checks (use netpol-findings); not for live cluster state (use kubectl); coverage is over ConfigHub-managed Units only.

Inventory and explore Kubernetes RBAC config stored in ConfigHub across the fleet, using the cub-rbac CLI. Use for "what RBAC do we have?", "list every ClusterRoleBinding", "which clusters have RBAC and how much?", "show all Roles in the payments namespace", "audit our RBAC footprint", "how many service accounts per cluster?". Not for "who can do X" effective-access queries (use rbac-whocan) or hygiene/risk analysis (use rbac-findings); not for live cluster RBAC (use kubectl); not for ConfigHub-entity permissions (out of scope).

Surface Kubernetes RBAC hygiene and risk issues across a ConfigHub fleet with the cub-rbac CLI: wildcard permissions, privilege-escalation verbs, risky grants (secrets/exec/webhooks/CRDs), cluster-admin bindings, orphaned bindings, and unbound service accounts. Use for "audit our RBAC hygiene", "any wildcard roles?", "who has cluster-admin?", "find privilege escalation", "any orphaned role bindings?", "show RBAC risks in prod". Analysis-only — enforcement is server-side via Triggers/ApplyGates. Not for inventory/listing (use rbac-audit) or effective-access who-can queries (use rbac-whocan); not for live cluster scanning (use a cluster scanner).

Apply RBAC changes across many ConfigHub Units at once with the cub-rbac CLI: bulk structured edits (fleet-edit) and override-preserving variant propagation from upstream (promote). Use for "add deletecollection to the developer role in every dev cluster", "remove the wildcard verb from this persona role fleet-wide", "add the oncall group to viewers across prod", "propagate the base RBAC change to all staging clones", "upgrade downstream RBAC units to their upstream", "which downstream units are behind their base?". Both are dry-run by default and require --commit + --change-desc; they never bypass ApplyGates and never apply to clusters. Not for a single Unit (use rbac-edit), not for inventory/queries (use rbac-audit / rbac-whocan), not for installing policy (use rbac-guardrails), not for rolling out to clusters (use cub-apply).

Answer Kubernetes effective-access questions across a ConfigHub fleet with the cub-rbac CLI: "who can VERB RESOURCE?" and the inverse "what can SUBJECT do?". Use for "who can delete secrets in prod?", "who can exec into pods?", "what can the ci-deployer service account do?", "which subjects have access to configmaps in payments?", "can anyone create clusterrolebindings?". Resolves RoleBindings/ClusterRoleBindings through their roles (including ClusterRole aggregation) and honors namespace scope and resourceNames. Not for inventory/listing (use rbac-audit) or risk/hygiene findings (use rbac-findings); not for live cluster authorization (use kubectl auth can-i).

Inventory and audit Kubernetes namespaces and their policy envelope (pod-security labels, default-deny NetworkPolicy, baseline RBAC) stored in ConfigHub across the fleet, using the cub-namespace CLI. Use for "what namespaces do we have?", "which namespaces are missing a default-deny / pod-security / baseline RBAC?", "is this namespace's envelope complete?", "per-cluster namespace/policy/workload counts", "list the namespaces in apptique". Not for cross-variant consistency (use namespace-consistency), ranked governance findings (use namespace-findings), or live cluster state (use kubectl); analysis is over ConfigHub-managed Units only.

Fix namespace-envelope gaps as config-as-data with the cub-namespace CLI — stamp pod-security defaults on a Namespace Unit (apply-envelope) and clone a base envelope's default-deny NetworkPolicy + baseline RBAC into an existing Space, re-homed with set-namespace (backfill). Use for "add pod-security labels to namespace X", "backfill the default-deny / RBAC into apptique-prod", "bring this namespace up to the envelope standard", "fix the missing-pod-security / missing-default-deny findings". Dry-run by default; requires --commit --change-desc. Not for read-only checks (use namespace-audit / namespace-findings) or enforcement Triggers (a later skill).

Check whether a component's namespace name and pod-security level are identical across all of its variant Spaces (environments / regions / clusters) in ConfigHub, using the cub-namespace CLI. Use for "is our namespace the same across dev/staging/prod?", "which components have drifted namespace names?", "is pod-security consistent across variants of X?", "check cross-variant namespace consistency". Not for per-namespace envelope completeness (use namespace-audit) or the full ranked findings list (use namespace-findings); read-only, ConfigHub-managed Units only.

Install, inspect, and feed the namespace-envelope guardrail pack in ConfigHub with the cub-namespace CLI — making envelope findings enforced (advisory ApplyWarnings) instead of just reported. Use for "enforce our namespace standards", "warn on namespaces without pod-security", "flag namespaces missing the envelope", "set up namespace guardrails", "which Units have namespace warnings?", "annotate the incomplete namespaces so they get flagged". Installs Warn=true vet-celexpr Triggers + a Filter (annotate-then-validate for envelope gaps); dry-run by default. Not for one-off checks (use namespace-findings) or fixing config (use namespace-backfill).

Run the ranked namespace-governance analyzer set over a ConfigHub fleet with the cub-namespace CLI — envelope gaps (missing default-deny / pod-security / baseline RBAC / Namespace object), duplicate namespaces colliding on a Target, and cross-variant name/pod-security inconsistency. Use for "what's wrong with our namespaces?", "namespace governance findings", "any duplicate namespaces?", "show high-severity namespace issues", "audit namespace hygiene". Not for raw inventory (use namespace-audit) or a single component's consistency detail (use namespace-consistency); read-only, ConfigHub-managed Units only.

Promote a namespace-envelope change from a base Space to every variant Space it was cloned into, with the cub-namespace CLI — an override-preserving upstream upgrade. Use for "roll out the tightened default-deny to all environments", "promote the envelope change to the downstream spaces", "upgrade the namespace policy Units to upstream head", "push the new required label everywhere". Dry-run by default; requires --commit --change-desc. Not for one-off edits (use namespace-backfill) or applying to a cluster (use cub-apply).

Answer effective NetworkPolicy connectivity questions across a ConfigHub fleet with the cub-netpol CLI: who is allowed to reach a workload, and what a workload is allowed to reach, under the combined policy set. Use for "who can reach the payments pods?", "what can the frontend talk to?", "is checkoutservice allowed to reach the database?", "which workloads can reach redis?". Computes reachability from NetworkPolicy isolation + ingress/egress rules (additive OR semantics). Not for inventory/coverage (use netpol-audit) or anti-pattern findings (use netpol-findings); not for live traffic (use a CNI flow tool).

Run NetworkPolicy hygiene and anti-pattern checks across a ConfigHub fleet with the cub-netpol CLI. Use for "audit our NetworkPolicy hygiene", "any namespaces missing a default-deny?", "any workloads uncovered on ingress?", "any allow-all policies?", "any egress to the cloud metadata IP?", "any ingress/egress asymmetry?". Reports findings (missing-default-deny-ingress, uncovered-ingress, allow-all, metadata-egress, ingress-egress-asymmetry) with severity. Not for plain inventory/coverage (use netpol-audit) or connectivity (use netpol-connectivity); read-only — fixing is netpol-fix.

Fix NetworkPolicy coverage gaps as data in ConfigHub with the cub-netpol CLI: create a default-deny for a namespace, author an allow policy between two workloads, derive allow policies from the ConfigHub dependency graph (Links), or patch an existing policy (add DNS egress, except the cloud-metadata IP). Use for "lock down the payments namespace", "allow frontend to reach checkout", "generate allow policies from our Links", "add the DNS allowance to this egress policy". All writes are dry-run by default and require --commit with a --change-desc; Units are created/edited but NOT applied to a cluster. Not for inventory/findings (use netpol-audit/netpol-findings), fleet-wide remediation (use netpol-fleet), or installing enforcement (use netpol-guardrails).

Fleet-wide NetworkPolicy operations in ConfigHub with the cub-netpol CLI: create a default-deny for every uncovered namespace at once, and promote a NetworkPolicy baseline from a base Space to its downstream cluster Spaces. Use for "default-deny every namespace that lacks one", "remediate all our coverage gaps", "roll the network-policy baseline out to all clusters", "which policy Units are behind their upstream?". Dry-run by default; requires --commit with --change-desc; Units are created/upgraded but NOT applied. Not for a single namespace/policy (use netpol-fix), inventory/findings (use netpol-audit/netpol-findings), or installing enforcement (use netpol-guardrails).

Install, inspect, and feed the NetworkPolicy guardrail policy pack in ConfigHub with the cub-netpol CLI — making NetworkPolicy findings enforced (advisory ApplyWarnings) instead of just reported. Use for "enforce our network-policy rules", "block allow-all policies", "warn on egress to 0.0.0.0/0", "set up NetworkPolicy guardrails", "which Units have NetworkPolicy warnings?", "annotate the uncovered Units so they get flagged". Installs Warn=true vet-celexpr Triggers + a Filter (annotate-then-validate for coverage); dry-run by default. Not for one-off checks (use netpol-findings) or fixing config (use netpol-fix).

Make guardrailed structured edits to a single Kubernetes RBAC Unit in ConfigHub with the cub-rbac CLI: add/remove a verb on a role rule, or add/remove a subject on a binding. Use for "give the viewer role get on pods", "remove the wildcard verb from this role", "add the oncall group to the admins binding", "revoke alice from breakglass", "drop the deletecollection verb". Edits are dry-run by default and require an explicit --commit with a --change-desc; they never bypass ApplyGates and never apply to the cluster. Not for inventory/queries (use rbac-audit / rbac-whocan), not for installing policy (use rbac-guardrails), not for applying/rolling out a change (use cub unit apply / the cub-apply skill).

Install and inspect the RBAC guardrail policy pack across a ConfigHub fleet with the cub-rbac CLI. Use for "enforce RBAC policy", "block wildcard roles / privilege escalation / cluster-admin bindings", "set up RBAC guardrails", "wire the guardrail triggers to my spaces", "which units have RBAC warnings?", "are our RBAC policies installed?". Installs three Warn=true Triggers in a policy Space and wires each in-scope Space's TriggerFilterID to a shared Filter; dry-run by default, --commit to apply. Not for one-off validation (use rbac-findings), not for editing RBAC config (use rbac-edit); promoting a guardrail to blocking and applying changes are done with cub directly.