Kubernetes Authenticator Client

This is an example application manifest describing the changes needed for configuration as a sidecar. Some details unrelated to authenticator configuration may vary based on your environment type or version.

Replace the variables in < > with values:

---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: test-app
  name: test-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: test-app
  template:
    metadata:
      labels:
        app: test-app
    spec:
      serviceAccountName: < APP_SERVICE_ACCOUNT_NAME >
      containers:
      - image: < TEST_APP_DOCKER_IMAGE >
        imagePullPolicy: Always
        name: test-app
        ports:
        - containerPort: 8080
        env:
          - name: CONJUR_APPLIANCE_URL
            value: "< CONJUR_APPLIANCE_URL >"
          - name: CONJUR_ACCOUNT
            value: < CONJUR_ACCOUNT >
          - name: CONJUR_AUTHN_TOKEN_FILE
            value: /run/conjur/access-token
          - name: CONJUR_SSL_CERTIFICATE
            valueFrom:
              configMapKeyRef:
                name: < CONFIG_MAP_NAME >
                key: ssl-certificate
        volumeMounts:
          - mountPath: /run/conjur
            name: conjur-access-token
            readOnly: true
      - image: cyberark/conjur-authn-k8s-client
        imagePullPolicy: Always
        name: <AUTHENTICATOR_CLIENT_CONTAINER_NAME>
        env:
          - name: MY_POD_NAME
            valueFrom:
              fieldRef:
                fieldPath: metadata.name
          - name: MY_POD_NAMESPACE
            valueFrom:
              fieldRef:
                fieldPath: metadata.namespace
          - name: MY_POD_IP
            valueFrom:
              fieldRef:
                fieldPath: status.podIP
          - name: CONJUR_AUTHN_URL
            value: "< CONJUR_AUTHN_URL >"
          - name: CONJUR_ACCOUNT
            value: < CONJUR_ACCOUNT >
          - name: CONJUR_AUTHN_LOGIN
            value: "< CONJUR_AUTHN_LOGIN >"
          - name: CONJUR_SSL_CERTIFICATE
            valueFrom:
              configMapKeyRef:
                name: < CONFIG_MAP_NAME >
                key: ssl-certificate
        volumeMounts:
          - mountPath: /run/conjur
            name: conjur-access-token
      imagePullSecrets:
        - name: dockerpullsecret
      volumes:
        - name: conjur-access-token
          emptyDir:
            medium: Memory

This is an example application manifest describing the changes needed for configuration as an init container. Some details unrelated to authenticator configuration may vary based on your environment type or version.

Replace the variables in < > with values:

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: test-app
  name: test-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: test-app
  template:
    metadata:
      labels:
        app: test-app
    spec:
      serviceAccountName: < APP_SERVICE_ACCOUNT_NAME >
      containers:
      - image: < TEST_APP_DOCKER_IMAGE >
        imagePullPolicy: always
        name: test-app
        ports:
        - containerPort: 8080
        env:
          - name: CONJUR_APPLIANCE_URL
            value: "< CONJUR_APPLIANCE_URL >"
          - name: CONJUR_ACCOUNT
            value: < CONJUR_ACCOUNT >
          - name: CONJUR_AUTHN_TOKEN_FILE
            value: /run/conjur/access-token
          - name: CONJUR_SSL_CERTIFICATE
            valueFrom:
              configMapKeyRef:
                name: < CONFIG_MAP_NAME >
                key: ssl-certificate
        volumeMounts:
          - mountPath: /run/conjur
            name: conjur-access-token
            readOnly: true
      initContainers:
      - image: cyberark/conjur-authn-k8s-client
        imagePullPolicy: Always
        name: <AUTHENTICATOR_CLIENT_CONTAINER_NAME>
        env:
          - name: CONTAINER_MODE
            value: init
          - name: MY_POD_NAME
            valueFrom:
              fieldRef:
                fieldPath: metadata.name
          - name: MY_POD_NAMESPACE
            valueFrom:
              fieldRef:
                fieldPath: metadata.namespace
          - name: MY_POD_IP
            valueFrom:
              fieldRef:
                fieldPath: status.podIP
          - name: CONJUR_AUTHN_URL
            value: "< CONJUR_AUTHN_URL >"
          - name: CONJUR_ACCOUNT
            value: < CONJUR_ACCOUNT >
          - name: CONJUR_AUTHN_LOGIN
            value: "< CONJUR_AUTHN_LOGIN >"
          - name: CONJUR_SSL_CERTIFICATE
            valueFrom:
              configMapKeyRef:
                name: < CONFIG_MAP_NAME >
                key: ssl-certificate
        volumeMounts:
          - mountPath: /run/conjur
            name: conjur-access-token
      imagePullSecrets:
        - name: dockerpullsecret
      volumes:
        - name: conjur-access-token
          emptyDir:
            medium: Memory

For each application we use with Conjur, we recommend creating a layer in policy to link an application's identity to the identities that can be used to authenticate to Conjur.

Replace the variables in < > with values:

---
- !policy
  id: test-app
  owner: !group devops
  annotations:
    description: This policy connects authn identities to an application identity. It defines a layer named for an application that contains the allowlisted identities that can authenticate to the authn-k8s endpoint. Any permissions granted to the application layer will be inherited by the allowlisted authn identities, thereby granting access to the authenticated identity.
  body:
  - !layer

 # add authn identities to application layer so authn roles inherit app's permissions
  - !grant
    role: !layer
    members:
    - !layer /conjur/authn-k8s/< AUTHENTICATOR_ID >/apps

Finally, we will define the secrets we wish to store in Conjur and the applications that should be granted access. In this sample policy, database credentials are stored in variables and access to these credentials is granted to the application identity layer we defined in the previous step.

- !policy
  id: test-summon-init-app-db
  owner: !group devops
  annotations:
    description: This policy contains the creds to access the summon init app DB

  body:
    - &init-variables
      - !variable password
      - !variable url
      - !variable username

    - !permit
      role: !layer /test-app
      privileges: [ read, execute ]
      resources: *init-variables

1. Save policy as .yml files in a location accessible to the Conjur master.

2. Log into Conjur.

3. Load each policy file:

   $ conjur policy load root <policy_for application_identity.yml>   $ conjur policy load root <policy_for application_secrets.yml>

CyberArk Conjur is a tool that reads identifiers for a set of secrets from a secrets.yml 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 will be 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 will need to be specified in the application manifest. The file is not immediately available but Summon will wait gracefully until the file exists before retrieving secrets.

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

The following is an example of a secrets.yml 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.

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

• Ruby (v5.3.1)

• Go (v0.5.0)

• Java (v2.0.0)

• .NET (v1.4.0)

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 will not be available until the authenticator client completes the authentication process so you will need to write logic that waits until the file is available before configuring the client.

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 on 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.

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 test applications that use the API to get secrets from Conjur.

The application can use the access token provided by the Kubernetes authenticator to retrieve secrets from the Conjur REST API. The token will need to 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. Note that it will not be available until the authenticator client performs its authentication process, so the application will need to wait until the file is available before making REST requests.

1. Make sure you are in the application namespace:

   kubectl config set-context <test-app-namespace-name>

2. Find your pod name:

   kubectl get pods

3. Display the logs:

   kubectl logs <pod-name> -c <k8s-authn-client-container>

1. Make sure you are in the application project:

   oc project <project-name>

2. Find your pod name:

   oc get pods

3. Display the logs:

   oc logs <pod-name> -c <k8s-authn-client-container>