Managed resources

This page is the authoritative list of what KCC actually owns in this repo. Counts are computed from the manifests in main and reflect what KCC reconciles, not what exists in GCP (drift is recovered by the controller on the next reconcile).

Note on secretmanager/ directories. Per the naming convention, directories are named after the Config Connector API group they correspond to. The secretmanager/ / secretsmanager/ directories are the one deliberate exception: they sit alongside the KCC API-group directories but contain External Secrets Operator resources (apiVersion: external-secrets.io/v1beta1 - SecretStore, ExternalSecret), not KCC resources. These resources bridge Postgres credentials from GCP Secret Manager into Kubernetes secrets and are reconciled by the ESO controller, not by KCC. They are called out explicitly in each project’s table below.

API groups in use

KCC ships one CRD per GCP API. The groups we have at least one resource of:

All resources use the v1beta1 channel of their API group (one compute/v1alpha1 exception exists in tb-platform-infra for an early-preview kind).

There is also one non-KCC API group co-located in these directory trees:

tb-infra-mgmt-project

GCP project: tb-infra-mgmt. This is the infra management project that hosts the GKE cluster running KCC itself, plus the build-cluster, Tailscale subnet routers, the platform PostgreSQL instance, Bufo’s Firestore databases, the Vault KMS unseal key, and the cross-project IAM bindings the platform infra team needs.

• Source: k8s/infra-services/tb-infra-mgmt-project/
• Namespace: tb-infra-mgmt-project
• ArgoCD app: infra-mgmt-project in apps/infra-mgmt-project.yaml
• AppProject: infra-mgmt
• Sync policy: manual sync, ServerSideApply=true, no prune

Resource composition:

Approximate kind footprint: 20 IAMServiceAccount, 17 IAMPartialPolicy, 11 IAMPolicyMember, plus the per-domain resources above. The 2 SecretStore / ExternalSecret resources in secretmanager/ are ESO-owned and excluded from the KCC count.

tb-infra-mgmt-vpc-project

GCP project: tb-infra-mgmt-vpc. The shared-VPC host project for the infra-management environment. Owns the VPC networks, regional subnets, router/NAT, IP addresses, and the Network Connectivity Center hub/spokes that wire the infra and tb-platform networks together.

• Source: k8s/infra-services/tb-infra-mgmt-vpc-project/
• Namespace: tb-infra-mgmt-vpc-project
• ArgoCD app: infra-mgmt-vpc-project in apps/infra-mgmt-vpc-project.yaml
• AppProject: infra-mgmt
• Sync policy: automated.prune: true, ServerSideApply=true

Resource composition:

tb-infra-security-project

GCP project: tb-infra-security (plus its parent Folder). The smallest of the infra projects - it exists to host security-team-owned IAM grants on a dedicated folder.

• Source: k8s/infra-services/tb-infra-security-project/
• Namespace: tb-infra-security-project
• ArgoCD app: infra-security-project in apps/infra-security-project.yaml
• AppProject: infra-mgmt
• Sync policy: manual sync, ServerSideApply=true, no prune

Resource composition:

tb-platform-infra

GCP target: the three tb-platform workload projects (tb-platform-dev, tb-platform-qa, tb-platform-prod), the three tb-platform VPC host projects (tb-platform-vpc-dev, tb-platform-vpc-qa, tb-platform-vpc-prod), and a small set of shared resources at the root.

This tree is the bulk of the KCC footprint: roughly 300 IAM resources, 60 DNS records, 60 compute resources, 20 storage buckets, plus GKE clusters, Cloud SQL instances, Memorystore Redis, KMS, Service Usage, Artifact Registry, and Cloud Run.

• Source: k8s/tb-platform-infra/
• AppProject: tb-platform-infra

Per-env structure

There are three flavours of KCC delivery for this tree:

Both ApplicationSets use the Argo git-directory generator so simply creating a new env/<name>/ directory will materialise a new ArgoCD Application pointing at it.

Workload projects (env/)

env/base/ defines the shared resource manifests; env/{dev,qa,prod}/ extend the base via kustomization.yaml and patches/. Each env owns a complete copy of the tb-platform workload project so dev never depends on prod IAM (or vice versa).

VPC host projects (vpc/)

vpc/base/ defines the shared VPC network and subnets; vpc/{dev,qa,prod}/ add the per-env host project, internal LB, PSC subnet, Cloud SQL endpoint, internal DNS records, and the secret-manager bridge for the env’s Postgres instance.

Shared root resources

The root kustomization deploys just the two shared resources:

# k8s/tb-platform-infra/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: tb-platform-infra
resources:
  - core/config-connector-context.yaml
  - iam/cluster-mgmt-sa.yaml

The shared ConfigConnectorContext makes the hub tb-platform-infra namespace KCC-enabled; iam/cluster-mgmt-sa.yaml defines the cluster-management IAMServiceAccount used by the GKE clusters across all three environments.

Naming conventions

Three rules apply repo-wide and are spelled out in k8s/tb-platform-infra/README.md:

1. Directory names map to API groups. iam/ for iam.cnrm.cloud.google.com, compute/ for compute.cnrm.cloud.google.com, resourcemanager/ for resourcemanager.cnrm.cloud.google.com, and so on. The base env/base/, env/<env>/, vpc/base/, vpc/<env>/ directories are the only deliberate exceptions.
2. Per-env overrides live in patches/. New env-specific resources go under env/<env>/<api-group>/. Modifications of base resources go in env/<env>/patches/.
3. One ConfigConnectorContext per namespace. Every directory whose kustomization targets a new namespace must include core/config-connector-context.yaml.

How to find a resource

If a resource isn’t found here, it isn’t managed by KCC and lives in Terraform under infra/ or the infra-terraform repo - see Working with Titanbay infra.