Application Identity in OpenShift/ Kubernetes
Security policy can be used to create identities for Kubernetes resources at multiple levels of granularity.
In most cases, you create an identity for your application based on its service account, or based on its controller such as a Deployment or StatefulSet. Then you configure your application pod to authenticate with DAP using this identity.
Once configured, the identity can be used by any pod deployed using the service account or the controller, providing a flexible way of sharing secrets among pods that may have common access needs.
By assigning identities to Kubernetes resources, you can use security policy to control the granularity and identity of the Kubernetes resources that authenticate to DAP and that can access secrets. The access usually occurs in the context of an application-specific policy, where specific roles are granted access to specific secrets.
Supported Kubernetes resources
The following are the Kubernetes resources that you can define as hosts:
|
Resource |
Description |
Use this level of granularity.... |
|---|---|---|
|
Namespace |
Authentication and secret access is by Kubernetes namespace. All resources in the namespace are controlled by the same grants and permissions. |
If all applications in the namespace share secrets, and if access to the secrets can be managed together. |
|
Deployment |
Authentication and secret access is by Kubernetes Deployment name within a namespace. |
If a group of stateless applications share secrets and access management rules. |
|
DeploymentConfig (OpenShift only) |
Authentication and secret access is by DeploymentConfig name (OpenShift Only) within a namespace. |
If a group of stateless applications share secrets and access management rules. |
|
StatefulSet |
Authentication is by Kubernetes StatefulSet name within a namespace. |
If a group of stateful applications share secrets and access management rules. |
|
Service Account |
Authentication is by Kubernetes service account name within a namespace. |
If you are already using service accounts to control access to secrets. You can build security policy on top of the service account access control. In this case, you will be managing both sets of access control for the same secrets. We recommend using this option as a transition, and move towards using the Kubernetes Deployment and StatefulSet resources as application identities. |
|
Pod |
Authentication is by Kubernetes Pod name within a namespace. |
For testing and proof of concept (POC). Pods tend to stop and restart too often to depend on them for security. |
Define Kubernetes Resources as DAP identities
In security policy, applications are represented as hosts and their identities are represented as annotations on the host resource. These annotations determine the granularity at which authentication is performed and access is granted.
|
Annotation format |
Description |
|---|---|
|
|
Authentication and secret access is by namespace name. With this format, all resources in a namespace are controlled by the same grants and permissions. |
|
|
Authentication and secret access is by |
|
(OpenShift only) |
Authentication and secret access is by |
|
|
Authentication and secret access is by stateful set name within a namespace. Grants and permissions are specific to a stateful set within a namespace. |
|
|
Authentication and secret access is by pod name within a named namespace. Grants and permissions are specific to a pod within a namespace. |
|
|
Authentication and secret access is by service account name within a namespace. Grants and permissions are specific to a service account within a namespace. |
Once you have decided on the granularity of authentication and secret access that you want to enforce, create the relevant host in your policy.
For example, to control authentication and secret access by the namespace-1 namespace, create the following policy:
|
where authn-k8s/authentication-container-name is the container name from which the host authenticates with DAP.
Save the policy as apps.yml and load it to root or to any other branch where you want the policy to reside.
When you define the application manifest to deploy your application, to authenticate with this host you add the full host id (in this example, host/apps/test-app)) to the application manifest (under CONJUR_AUTHN_LOGIN). For more information about defining the host and host id in the application manifest, see the section relevant to the method in which you deploy applications.
Examples of host annotations
|
