Machine Identity

Conjur policy can be used to create identities for Kubernetes resources at multiple levels of granularity. In most cases, you will want to create an identity for a controller resource such as a deployment or stateful set, or a service account and configure your application pod to authenticate with Conjur using this identity. The identity can then be used by any pod deployed using the given controller or service account, providing a flexible way of sharing secrets amongst application pods that may have common access needs.

Conjur hosts

By assigning machine identities to Kubernetes resources, you can use Conjur policy to control:

  • The granularity and identity of the Kubernetes resources that authenticate to Conjur.

  • The granularity and identity of the Kubernetes resources that can access secrets. The access usually occurs in the context of an application-specific policy, where specific host roles are granted access to specific secrets.

To assign machine identity, use policy to declare a desired Kubernetes resource as a Conjur host.

The following are the Kubernetes resources you can define as Conjur hosts, including usage guidelines.

Resource

Description

Use this level of granularity if...

Namespace

Authentication and secret access is by Kubernetes namespace. All resources in the namespace are controlled by the same grants and permissions.

All applications in the namespace share secrets and access to the secrets can be managed together.

Deployment

Authentication and secret access is by Kubernetes deployment name within a namespace.

A group of stateless applications share secrets and access management rules.

Deployment Config (OpenShift only)

Authentication and secret access is by OpenShift deployment config name within a namespace.

A group of stateless applications share secrets and access management rules.

Stateful Set

 

Authentication is by Kubernetes stateful set name within a namespace.

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 Conjur policy on top of the service account access control. However, be aware that you will then 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 stateful set resources as hosts.

Pod

Authentication is by Kubernetes pod name within a namespace.

For testing and proof of concept. Pods tend to stop and restart too often to depend on them for security.

Host Ids

The host ids represent Kubernetes resources. The format of the host id determines the granularity of authentication and secret access that you want to enforce.

Format

Description

[namespace]/*/* Authentication and secret access is by namespace. The two asterisks are wildcards for all Kubernetes resource types and all resource names within the namespace. With this format, all resources in a namespace are controlled by the same grants and permissions. 
[namespace]/deployment/[name] Authentication and secret access is by deployment name within a namespace. Grants and permissions are specific to a deployment within a namespace.
[namespace]/deployment_config/[name] Authentication and secret access is by OpenShift deployment config name within a namespace. Grants and permissions are specific to a deployment config within a namespace.
[namespace]/stateful_set/[name] Authentication and secret access is by stateful set name within a namespace. Grants and permissions are specific to a stateful set within a namespace.
[namespace]/pod/[name] Authentication and secret access is by pod name within a named namespace. Grants and permissions are specific to a pod within a namespace.
[namespace]/service_account/[name] Authentication and secret access is by service account name within a namespace. Grants and permissions are specific to a service account within a namespace.

The authentication service prepends the namespace in your host id with additional known information, transforming the entire host id value to host/conjur/authn-k8s/<webservice>/apps/<namespace>/...

When the two asterisks are used to represent all resources in a namespace, the host id becomes host/conjur/authn-k8s/<webservice>/apps/<namespace>/<controller_type>/<controller_id>

Example host ids

 
body:
    - !layer
      - &hosts                                    
	  # list hosts here
        - !host
          id: namespace-1/*/*                     
	  # namespace-1 authenticates. The wildcards are required.

        - !host
          id: namespace-1/deployment/web03        
	  # deployment 'web03' in namespace 'namespace-1' authenticates.

        - !host
          id: namespace-1/deployment_config/web04 
	  # OpenShift deployment config 'web04' in namespace 'namespace-1' authenticates.

        - !host
          id: namespace-2/stateful_set/db         
	  # stateful set 'db' in namespace 'namespace-2' authenticates.

        - !host
          id: namespace-2/pod/pod-10              
	  # pod-10 in namespace-2 authenticates.

        - !host
          id: namespace-3/service_account/sa-20   
	  # sa-20 in namespace-3 authenticates.
 
True