Kubernetes Authenticator Client

This topic describes step-by-step how to set up the Kubernetes Authenticator Client so that an application in Kubernetes can retrieve secrets from Conjur.

How it works

This section describes how the application container fetches secrets from Conjur.

  1. The Kubernetes Authenticator Client starts and authenticates to Conjur using the Kubernetes Authenticator.

  2. Conjur returns a Conjur access token.

  3. The Conjur access token is shared between the Kubernetes Authenticator Client container and the application container using a shared memory volume between the container.

  4. The application container can now use the Conjur access token to fetch secrets from Conjur.

Set up the application to retrieve secrets

This section describes how to set up the Kubernetes Authenticator Client so that your application can retrieve secrets from Conjur.

 

This procedure involves tasks for both the application owner and the Conjur admin. If you do not have Conjur admin permissions, make sure that your Conjur admin is available when you perform these tasks.

Prepare applications to retrieve secrets

Use the one of the following methods to enable applications to retrieve secrets from Conjur.

Conjur provides client libraries in a variety of languages that can be integrated into an application to facilitate secret retrieval:

The access token retrieved by the Kubernetes Authenticator Client is written to the volume shared with the application container at /run/conjur/access-token. This file can be read and used with the client libraries to talk to Conjur. The token is not available until the Kubernetes Authenticator Client completes the authentication process so you need to write logic that waits until the file is available before configuring the client.

 

The token is not available until the Kubernetes Authenticator Client performs its authentication process, so the application needs to wait until the file is available before making REST requests.

Using API calls, the application gets the access token from the shared volume (/run/conjur/access-token), authenticates to Conjur, and then requests secrets.

The access token may not be available immediately upon application startup. The application may need to wait for the volume to mount, the authentication to occur, and the access token to be written into the shared file.

 

The conjur-api-go API handles the wait gracefully and seamlessly.

For other APIs, the application containers should check for the file on startup and retry until the file exists.

Additional resources
  • See DockerHub for more information about the API and the access token. The same sidecar is used for both Kubernetes and OpenShift integrations.

  • See our demo repository for examples of complete Conjur deployments and applications that use the API to get secrets from Conjur.

The application can use the access token provided by the Authenticator to retrieve secrets from the Conjur REST API. The token must be included in the Authorization header when making a request against the retrieve secret endpoint.

The application can read the access token from the shared volume at /run/conjur/access-token. It is not available until the Kubernetes Authenticator Client performs its authentication process, so the application must wait until the file is available before making REST requests.

For more information, see Authenticate using REST APIs.

CyberArk Conjur is a tool that reads identifiers for a set of secrets from a secrets.yaml file, uses the identifiers with a provider to retrieve the secret values from some source, and injects the secrets into an the environment variables of an application run as a subprocess. The secret values exist only in memory and are discarded when the process exits.

To retrieve secrets with Summon, both Summon and the summon-conjur provider must be installed into the application container. See our Kubernetes demo repo for an example of how to perform this installation in a Docker container using the installation scripts for the respective tools.

Summon reads the access token it needs to communicate with Conjur from the file specified by the CONJUR_AUTHN_TOKEN_FILE variable in the application's environment, which must be specified in the application manifest. The file is not immediately available but Summon waits until the file exists before retrieving secrets.

Summon reads the identifiers for the secrets that an application needs from a secrets.yaml file.

The following is an example of a secrets.yaml file showing multiple types of allowed entries.

 
DB_USERNAME: !var my-app/db/username
DB_PASSWORD: !var my-app/db/password
REGION: us-east-1
SSL_CERT: !var:file ssl/certs/private
  • Lines 1 and 2 specify variables with pathnames containing a secret. In this case, assume that a policy with an id of my-app was loaded into Conjur.

  • Line 3 specifies a literal string for the secret.

  • Line 4 specifies a variable that is a file containing the secret. The contents of the file would also be retrieved from Conjur.

Security consideration

Users who can create a Pod that can authenticate to Conjur can also access Conjur access tokens. As a result, these users can access the Pod's Conjur secrets.