Access to Sensitive Data: KCSA practice questions

Sensitive data in a cluster is mostly credentials and configuration: Secrets, ServiceAccount tokens, TLS keys and whatever applications write to their logs. The CNCF Financial Services User Group attack tree for this goal names three main approaches: reading Secret data directly by exploiting misconfigured RBAC permissions, viewing sensitive data stored in logs, and eavesdropping on network traffic. Mitigations line up against each of them.

Start with storage. Secrets are stored unencrypted in etcd by default, so anyone with access to etcd can read them. Encryption at rest is configured with a file passed to kube-apiserver through --encryption-provider-config. Its providers list is ordered: the first provider encrypts everything that is written, and the others are only tried when reading. identity, the default, writes resources as-is, so listing it first means no encryption at all. Among the local providers, aescbc is rated weak and aesgcm keys must be rotated every 200,000 writes, and the documentation cautions that a raw key stored in the configuration file only moderately improves security compared with no encryption; for additional secrecy it suggests the kms provider, whose keys are held outside the cluster. etcd itself also needs guarding: any client certificate signed by a CA that etcd trusts gives full read and write access, even one issued only for health checks, because etcd has no widely accepted authorization model.

Then the API. Anyone with API access to a Secret can retrieve or modify it, and the RBAC good-practices guide stresses that list and watch reveal Secret contents just as get does, since a List response returns the complete objects. Anyone allowed to create a Pod in a namespace can read every Secret there by mounting it, including indirectly through a Deployment, so least privilege covers workload creation as much as the secrets resource. Restricting Secret access to the specific containers that need it and using an external secret store provider are the other documented steps.

On the node, a Secret is only sent to a node if a Pod there requires it, and the kubelet keeps mounted Secret data in a tmpfs so it is not written to durable storage. The ServiceAccount token mounted into Pods by default is itself sensitive; setting automountServiceAccountToken: false where a workload never calls the API removes it.

Logs are the second route, and that includes the audit log. Audit events recorded at the Metadata level capture the requesting user, timestamp, resource and verb without request or response bodies, and the documentation's example policy logs Secret and ConfigMap changes at that level, so their contents are not written to the audit trail.

The network is the third route. The security checklist asks for mutual TLS to etcd with a certificate authority unique to etcd, and, because not every CNI plugin provides encryption in transit, suggests a service mesh to encrypt communication inside the cluster where appropriate.