Policy Segregation for Kubernetes
When using Akeyless Kubernetes Authentication, policy segregation of resources can be done based on Kubernetes attributes via Akeyless RBAC using the relevant sub-claims, such as
The following guide will demonstrate the usage of namespace segregation.
Controlling the Capabilities of a Workload
Authorization in Kubernetes is intentionally high level, focused on coarse actions on resources. However, policies enable you to limit, by use case, how objects act on the cluster, themselves, and other resources. You can use policies, together with the Akeyless native injector, to support full and flexible segregation.
Namespace and Pod Segregation
To fully segregate your cluster workloads so that your cluster namespaces/pods have different authorizations for the Akeyless Vault Platform, you can use Akeyless Kubernetes Auth.
For each required policy:
- Create an authentication method. For details about the authentication methods that are supported for K8s, see Authentication Methods for K8s.
The following example uses a pre-defined Kubernetes Auth method called K8s_Auth in the K8s folder. Follow this guide to create a Kubernetes Auth method.
While it is not mandatory to separate the authentication methods and access roles into separate folders, we recommend that you do this to keep things organized.
akeyless create-secret --name K8s/NameSpaces/Folder/Secrets/namespace1 --value MySecret
- Create an access role to provide the authentication method with access to the required secret. For example, the following commands create the namespace1role role in the Role folder found in /K8s/NameSpaces/Folder/, associate the role with the namespace1auth authentication method, and grant read, list, access to the namespace1 secret in the Secrets folder found in /K8s/NameSpaces/Folder/. Where on the association specify the desired sub-claims such as
akeyless create-role --name /K8s/NameSpaces/Folder/Role/namespace1role
Associate the role with your authentication method and the relevant sub claim, in the following example only pods from
namespace1 will be authorized:
akeyless assoc-role-am --role-name /K8s/NameSpaces/Folder/Role/namespace1role --am-name /K8s/NameSpaces/Folder/Auth/namespace1auth --sub-claims namespace=namespace1
Set the role rule and capabilities:
akeyless set-role-rule --role-name /K8s/NameSpaces/Folder/Role/namespace1role --path /K8s/NameSpaces/Folder/Secrets/namespace1 --capability read --capability list
The Akeyless webhook validates the role-based access rule for each namespace. If the namespace is authorized, Akeyless searches in the secrets folder you defined for the appropriate secret.
kubectl create namespace namespace1
For example, if we deploy the YAML under namespace1, and we will try to fetch the namespace1 secret:
apiVersion: apps/v1 kind: Deployment metadata: name: test spec: replicas: 1 selector: matchLabels: app: hello-secrets template: metadata: labels: app: hello-secrets annotations: akeyless/enabled: "true" spec: containers: - name: alpine image: alpine command: - "sh" - "-c" - "echo $MY_SECRET && echo going to sleep... && sleep 10000" env: - name: MY_SECRET value: akeyless:K8s/Path/To/NameSpaces/Folder/Secrets/namespace1secret
kubectl apply -f SegregationForNamespace1.yaml -n namespace1
Updated 6 months ago