Image Pull Secrets at Scale

Pulling private images. The patterns.

Per-namespace

Image pull secrets are how Kubernetes authenticates to private container registries. The naive approach is per-pod configuration; the discipline is per-namespace or operator-managed configuration. The right approach scales without operational burden.

What per-namespace pull secrets provide:

• Pull secret in each namespace.: The namespace has its own pull secret. Pods in the namespace reference it; the registry authentication is namespace-scoped.
• Granular.: Different namespaces can have different pull secrets. Different teams using different registries; the namespace-level scoping accommodates this.
• But tedious.: The cost is operational. Every new namespace needs its pull secret created; rotation requires updating each namespace; the per-namespace work adds up.
• Manual creation is error-prone.: Manual secret creation produces typos, forgotten namespaces, inconsistent secrets. The errors are bugs that surface later as image pull failures.
• Audit overhead.: Many secrets means many things to audit. The team's secret inventory grows; the audit covers more material.

Per-namespace pull secrets work but the operational cost is real. Most teams progress beyond this approach.

ServiceAccount

Pull secrets can be attached to ServiceAccounts. Pods using the ServiceAccount inherit the pull secret automatically; per-pod configuration is eliminated.

• Default ServiceAccount with imagePullSecret.: The namespace's default ServiceAccount has the pull secret attached. Pods that do not specify a ServiceAccount use the default; they inherit the pull secret.
• Less per-pod config.: Pod manifests do not need imagePullSecrets entries. The configuration is at the ServiceAccount level; the pods are simpler.
• Cleaner manifests.: The manifests look cleaner; the boilerplate is reduced; the focus is on what the pod does, not on infrastructure detail.
• Per-ServiceAccount granularity.: Different ServiceAccounts can have different pull secrets. A namespace can have multiple ServiceAccounts; each can have its own registry access.
• Standard pattern.: The ServiceAccount-based approach is the standard for production. Most Kubernetes templates and tools assume it.

ServiceAccount-based pull secrets reduce per-pod configuration. The pattern scales better than per-pod.

Automate

The fully automated approach uses an operator. The operator creates and manages pull secrets across namespaces; the team's manual work is eliminated.

• Operator that creates pull secrets per namespace.: An operator watches for namespace creation; when a new namespace appears, the operator creates the pull secret. The configuration is centralized; each namespace is configured automatically.
• Scales without manual.: Adding namespaces does not require manual secret creation. The operator handles it; the team's burden does not grow with namespace count.
• Rotation is automated.: When the pull secret needs rotation, the operator handles it across all namespaces. The rotation is one operation; the operator propagates.
• Drift detection.: The operator can detect drift: namespaces missing the pull secret, secrets with wrong values. The drift is corrected automatically; the team's discipline is enforced by tooling.
• Common operators.: Tools like reflector, kubed, or custom controllers fill this role. Some teams build their own; the operator is bounded code; the value is significant.

Image pull secrets is one of those operational disciplines that pays off at scale. Nova AI Ops integrates with cluster secret management, surfaces pull-secret coverage and rotation status, and produces the visibility that the platform team uses to keep registry access healthy.