Remote bases & supply chain

Pinning and trusting external bases.

Advanced12 min · lesson 10 of 12

A kustomization can reference a remote base by URL — a Git repo, a specific path and ref — so you can build on shared manifests published elsewhere (a platform team’s base, an upstream project’s install manifests). It is powerful for reuse, and it is a supply-chain surface: a remote base contributes real resources to your build, so whoever controls that URL controls part of what you deploy.

kustomization.yaml

resources:
  # pin to an exact ref (tag or commit SHA), never a moving branch
  - github.com/acme/platform-base//overlays/secure?ref=v1.4.0
  - ./deployment.yaml

Pin, review, and prefer vendoring

Treat a remote base like any dependency: pin it to an immutable ref (a tag or, best, a commit SHA) rather than ?ref=main, which pulls whatever that branch is today. For high-assurance setups, vendor the base into your repo (copy it in, or use a tool that does) so your build does not depend on a live external fetch and you review changes as diffs. Always kustomize build and inspect what a remote base actually contributes.

terminal

$ kustomize build . | kubeconform -strict     # validate the assembled result
# review exactly what the remote base added before applying — it is code you run

A remote base on a moving branch is untrusted live code

Referencing github.com/x/y//path (no ref, or ?ref=main) means your deploy changes whenever that branch changes — a compromised or careless upstream can inject resources into your cluster. Pin to a tag/SHA, review updates deliberately, prefer vendoring for anything you cannot fully trust, and never build remote bases you have not inspected: the build output is what runs.

Secrets done safelyKustomize vs Helm (and together)