Skip to content
LatchkeyLatchkey home

kubectl create secret: Command Reference for CI/CD

Build a Secret from literals, files, or registry credentials.

kubectl create secret builds Secrets from flags: generic key/value, docker-registry pull credentials, or tls cert/key pairs. This reference covers the subcommands and the pipe-to-apply pattern that makes secret creation idempotent in re-run pipelines.

Common flags and usage

  • create secret generic <name> --from-literal=k=v: inline key/value
  • --from-file=<path>: load a file as a Secret key
  • --from-env-file=<file>: load many keys from a dotenv file
  • create secret docker-registry: an imagePullSecret
  • create secret tls <name> --cert=... --key=...: a TLS pair

Example

shell
kubectl create secret generic db-creds \
  --from-literal=password=${DB_PASSWORD} \
  --dry-run=client -o yaml | kubectl apply -f -

kubectl create secret docker-registry regcred \
  --docker-server=ghcr.io --docker-username=ci \
  --docker-password=${{ secrets.GHCR_TOKEN }} \
  --dry-run=client -o yaml | kubectl apply -f -

In CI

A plain create secret fails with AlreadyExists on a re-run. Pipe through apply (--dry-run=client -o yaml | kubectl apply -f -) so the value is updated idempotently. Pass secret values from your CI secret store, never inline literals committed to the repo.

Using this in CI

A runner has no kubeconfig, no cached context, and no interactive auth. Every kubectl invocation in CI needs the context supplied explicitly, and most confusing CI failures here are the command running against the wrong cluster or no cluster at all.

Terminal
# never rely on the ambient context on a runner
kubectl --context "$KUBE_CONTEXT" -n "$NAMESPACE" get pods

# confirm what you are actually connected to before mutating anything
kubectl config current-context
kubectl cluster-info

# fail fast instead of hanging on an unreachable API server
kubectl --request-timeout=30s get nodes

Key takeaways

  • create-pipe-apply makes secret creation idempotent across re-runs.
  • docker-registry secrets are the standard imagePullSecret.
  • Source values from the CI secret store, not committed literals.

Frequently asked questions

kubectl create secret: Command Reference for CI/CD?
kubectl create secret builds Secrets from flags: generic key/value, docker-registry pull credentials, or tls cert/key pairs. This reference covers the subcommands and the pipe-to-apply pattern that makes secret creation idempotent in re-run pipelines.
In CI?
A plain create secret fails with AlreadyExists on a re-run. Pipe through apply (--dry-run=client -o yaml | kubectl apply -f -) so the value is updated idempotently. Pass secret values from your CI secret store, never inline literals committed to the repo.

Related guides

References

Latchkey auto-heals failures like this one - detected, fixed, and retried without you. Start free → 30-day trial · No credit card