Secrets Provider - init container/sidecar - Push-to-File mode

This topic describes how to deploy the CyberArk Secrets Provider for Kubernetes as an init container or sidecar, cyberark-secrets-provider-for-k8s, in Push-to-File mode.

In Push-to-File mode, the Secrets Provider pushes Conjur secrets to one or more secrets files in a shared volume in the same Pod as your application container.

To convert existing application deployments that push Conjur secrets to Kubernetes Secrets to push to secrets files instead, see Convert existing Secrets Provider deployments to Push-to-File.

How it works

In Push-to-File mode, the Secrets Provider enables your application to consume Conjur secrets from secrets files in a shared volume in the same Pod as the application container.

  1. The Secrets Provider is deployed as a sidecar/init container in the same Pod as your application container. The Secrets Provider starts up and parses Pod annotations from a Kubernetes Downward API volume. The Pod annotations are organized in secret groups, with each secret group indicating to the Secrets Provider:

    • The policy paths from which Conjur secrets should be retrieved.

    • The format of the secrets file to be rendered for that group.

    • How retrieved Conjur secret values should be mapped to fields in the rendered secrets file.

  2. The Secrets Provider authenticates to Conjur using the Kubernetes Authenticator (authn-k8s).

  3. The Secrets Provider reads all Conjur secrets required across all secret groups.

  4. The Secrets Provider renders secrets files for each secret group, and writes the resulting files to a volume that is shared with your application container.

  5. If the Secrets Provider is an init container, it runs to completion.

    If the Secrets Provider is a sidecar and is configured to refresh secrets, after a specified interval the Secrets Provider checks if there are any updates to the secrets in Conjur. If changes are detected, the Secrets Provider sidecar updates the secrets files in the shared volume.

    Moreover, the application can optionally delete secret files after consuming them. In this case. if changes are detected in the secrets in Conjur, the Secrets Provider sidecar recreates and rewrites the secret files to the shared volume.

  6. Your application container starts and consumes the secrets files from the shared volume.

Secret rotation and update detection

Supported by the Secrets Provider sidecar only.

If secrets are updated or if secrets rotation is enabled, the Secrets Provider sidecar container updates the secrets in the secrets files.

After a specified interval (default or specified by annotation in the Secrets Provider manifest), the Secrets Provider checks if the secrets have changed by comparing the SHA-256 checksums of the secrets with the previous checksums. The Secrets Provider does not save any of the unencrypted secrets.

If the time needed to fetch the secrets is longer than is specified for the interval, then the internal will be the actual time to retrieve the secrets.

For example: if the duration is set to two seconds, but retrieving the secrets takes three seconds, then the secrets are updated every three seconds.

If a secret is deleted from Conjur or if access to the secret has been revoked, the Secrets Provider deletes the secrets file from the shared volume.

Set up Secrets Provider as an init container/sidecar in Push-to-File mode

This section describes how to set up the Secrets Provider for Kubernetes as an init container/sidecar in Push-to-File mode.

Check Secrets Provider status using sentinel files

Supports Secrets Provider v1.4.1 and later.

Secrets Provider allows for its status to be monitored through the creation of two empty sentinel files: CONJUR_SECRETS_PROVIDED and CONJUR_SECRETS_UPDATED.

The CONJUR_SECRETS_PROVIDED file is created when the Secrets Provider has completed its first round of providing secrets via secret files. It creates or recreates the CONJUR_SECRETS_UPDATED file whenever it has updated secret files. If needed, application containers can mount these files via a shared volume.

The Pod would need a Volume defined as follows:

    - name: conjur-status
        medium: Memory

The application container and Secrets Provider container would need to include volumeMounts as follows:

    - mountPath: /conjur/status
      name: conjur-status

The sentinel files delay the start of the application until after the Secrets Provider has started up and written the secrets. Kubelet starts the Pod containers in the order they are listed in the manifest. A postStart lifecycle hook can be added to the Secrets Provider manifest to delay the start of the application container until the postStart lifecycle hook is complete.

              - /usr/local/bin/

For an example of the Secrets Provider script, see conjur-secrets-provided.

If a livenessProbe is not already being used by the container as a health probe, you can use a livenessProbe as a "file watcher" and can cause the application to be restarted after the secrets have been updated. The livenessProbe could look as follows:

            - /conjur/status/
          failureThreshold: 1
          initialDelaySeconds: 5
          periodSeconds: 5
          successThreshold: 1
          timeoutSeconds: 1

Secrets files deletion after consumption

Container type



By default, the Secrets Provider sidecar deletes secrets files from the shared volume when a secret is deleted from Conjur or if access to the secret is revoked.

You can disable this behavior by including the = false annotation in the sidecar manifest.


Kubernetes does not currently restart init containers if primary (i.e. non-init) containers crash and cause liveness or readiness probe failures. When the Secrets Provider is defined as an init container, meaning that it is not restarted, secret files are not recreated following liveness or readiness failures.

We therefore recommend that applications should not delete secrets files after consuming the files.