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 Conjur 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 Conjur 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 Conjur 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

authn-k8s/namespace

Authentication and secret access is by namespace name.

With this format, all resources in a namespace are controlled by the same grants and permissions. 

authn-k8s/deployment

Authentication and secret access is by Deployment name within a namespace. Grants and permissions are specific to a Deployment within a namespace.

authn-k8s/deployment-config

(OpenShift only)

Authentication and secret access is by DeploymentConfig name (OpenShift only) within a namespace. Grants and permissions are specific to a DeploymentConfig within a namespace.

authn-k8s/stateful-set

Authentication and secret access is by stateful set name within a namespace. Grants and permissions are specific to a stateful set within a namespace.

authn-k8s/pod

Authentication and secret access is by pod name within a named namespace. Grants and permissions are specific to a pod within a namespace.

authn-k8s/service-account

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:

 
- !policy
  id: apps
  body:
    - !group
      
    - !host
      id: test-app
      annotations:
        authn-k8s/namespace: namespace-1
        authn-k8s/authentication-container-name: test-container
  
    - !grant
      role: !group
      member: !host test-app

where authn-k8s/authentication-container-name is the container name from which the host authenticates with Conjur.

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

 
- !host
  id: test-app
  annotations:
    authn-k8s/namespace: <namespace>
    authn-k8s/service-account: <service-account>
    authn-k8s/deployment: <deployment>
    authn-k8s/deployment-config: <deployment-config>
    authn-k8s/pod: <pod>
    authn-k8s/stateful-set: <stateful-set>