Disabling creation of secrets in an AKS Cluster?

[John Peters (johnpetersjr)]

Hi all,

I'd like to try using an Azure Policy to enforce users to not store / use secrets in their namespaces. Has anyone tried this before?

I have given the users a way to seamlessly connect to an Azure Vault from their pods using managed identities, so they can get secrets directly from there. My security team would like to see no-one using a Kubernetes Secret ever again, if possible, hence my thought of disabling AKS secrets...

I was thinking along the lines of this built-in policy ContainerDisalllowedCapabilities to essentially white-list things like nginx or kube-system in case they really need to use secrets, but then block all other namespaces from the 'capability' of using secrets.

Is this possible? Or is this a different/better way to do this?

[André Lademann (vergissberlin)]

One correction first: ContainerDisallowedCapabilities won't help. That policy governs Linux kernel capabilities on containers (NET_ADMIN, SYS_PTRACE and friends) - it has nothing to do with the v1/Secret resource, so there's no "secrets capability" to revoke there.

Two mechanisms actually apply. RBAC is the simpler and arguably better one: don't grant create on secrets in the Roles you bind for tenant namespaces. That's least-privilege by construction, needs no admission controller, and fails with a clear message. If it has to be enforced centrally regardless of who writes RoleBindings, Azure Policy for AKS is Gatekeeper underneath, so you'd ship a custom ConstraintTemplate denying CREATE/UPDATE on v1/Secret with namespace exclusions. There's no built-in definition for that, so expect a custom policy.

The caveat that usually causes a rollback: Secrets are load-bearing in places that aren't user-facing. Helm 3 stores release state in Secrets, so helm install breaks. Ingress TLS, imagePullSecrets and cert-manager all write Secrets. The Key Vault CSI driver writes one too if anyone uses secretObjects to sync into the cluster - so if you go this route, mandate the volume mount only and forbid secretObjects.

Worth pinning down what your security team is actually worried about, though. If it's secret material sitting in etcd, KMS etcd encryption addresses that directly and costs you none of the above. If it's credentials pasted into YAML in git, that's cheaper to catch in CI than at the API server. Banning the resource outright is a fairly blunt instrument for either concern.