6.5.8 Kubernetes

Set the kubectl context, namespace, secret name, and RBAC permissions

The Kubernetes TLS secret template creates or replaces a kubernetes.io/tls secret with kubectl.

Requirements

  • Install kubectl on the Linux agent host.
  • Configure a kubeconfig and current context for the identity running the CertKit agent.
  • Grant that identity permission to get, create, and update secrets in the target namespace.
  • Ensure the agent can reach the Kubernetes API server.

Set the secret and namespace

The built-in script uses the placeholder secret name my-tls and the current namespace:

kubectl create secret tls my-tls \
  --cert="$CERT_PATH" \
  --key="$KEY_PATH" \
  --dry-run=client -o yaml | kubectl apply -f -

Copy or customize the template to set the secret name and, when needed, add --namespace. Use the same name referenced by the Ingress, Gateway, or workload configuration.

Context and service-account troubleshooting

Run checks as the same operating-system identity used by the CertKit agent. kubectl may work for an interactive administrator while the agent service has no kubeconfig or uses another context.

Confirm the active target and authorization before deploying:

kubectl config current-context
kubectl auth can-i get secrets --namespace YOUR_NAMESPACE
kubectl auth can-i create secrets --namespace YOUR_NAMESPACE
kubectl auth can-i update secrets --namespace YOUR_NAMESPACE

After deployment, confirm that the secret has a new resource version and that the consuming ingress controller or workload has reloaded it. CertKit updates the secret; reload behavior is controlled by the Kubernetes component that consumes it.

For a product overview, see certificate automation for Kubernetes.