Using effective access control policies for PII (e.g., name, address, social security number, telephone number, email address) and SPI (e.g., biometric data, gender, race, height, weight, sex, trade union membership, and sexual orientation) is a crucial part of this step. Kubernetes API server limits individual users' ability to access computers or network resources and perform various tasks based on their roles within an organization (role-based access control - RBAC).
In actual practice, it is important to ascertain whether users who call up APIs associated with sensitive data are indeed who they say they are before they are granted access. The authentication is carried out by an identity provider (IdP) on behalf of the service provider and the IdP maintains an audit trail of every transaction it handles. Further, Open Policy Agent (OPA) policy engine can be used to enforce more granular policies, involving access to sensitive data. This goes beyond what RBAC can hope to achieve. Working together, RBAC, IdP service, and OPA can serve as a reliable approach to ensure sensitive information is available to users strictly on a need basis.
NIST CSF urges organizations to identify potential vulnerabilities in assets and document how they plan to remedy these issues. For instance, Kubernetes "Namespaces" provide a mechanism for isolating multiple users or applications using a single shared cluster, and this is particularly significant in scenarios involving a large number of users, teams, and projects. The shared cluster is partitioned into multiple virtual clusters, and strict rules are enforced around, say, who can or cannot create or modify pod instances. The result is that each user or application exists within its Namespace, completely secluded from other users and applications. This helps check unintended interactions between users/applications. Besides, since Kubernetes operates on the principle of least privilege, users and applications only have access to the resources they need to carry out their operations.
Mutual transport layer security (mTLS), in which the client identity is also authenticated in addition to the credentials of the server, is especially suited for securing cross-application communication in Kubernetes. The mTLS process ascertains whether an authenticated call is indeed from a client application that is permitted to access the data in question. Besides, Kubernetes network policy makes it possible to allow or block traffic flow between pods at the IP address/port level.
For added protection, Kubernetes provides for frequent rotation of cluster credentials, such as the private key for the cluster root certificate authority (used to authenticate the API server and by the API server to validate the kubelet client certificate). Credential rotation also changes the IP address used by the control plane to provide service or information to the Kubernetes API. It's best to rotate application credentials on a daily or at least monthly basis.
Kubernetes encrypts data at rest (stored data) in etcd, a key-value database, making use of a key management service (KMS), an add-on that runs as a static pod on a master node. The data encryption keys are further encrypted using a key encryption key and stored away securely in a remote KMS.