Table of Contents

• Table of Contents
• CyberArk Secrets Provider for Kubernetes
  • Supported services
  • Using This Project With Conjur Open Source
  • Methods for Configuring Secrets Provider
  • Enabling Tracing
• Releases
  • Stable release definition
• Development
• Documentation
• Community
• License

CyberArk Secrets Provider for Kubernetes

The CyberArk Secrets Provider for Kubernetes provides Kubernetes-based applications with access to secrets that are stored and managed in Conjur.

Consuming Secrets from CyberArk Secrets Provider

Using the CyberArk Secrets Provider, your applications can easily consume secrets that have been retrieved from Conjur in one of two ways:

• Using Kubernetes Secrets: The Secrets Provider can populate Kubernetes Secrets with secrets stored in Conjur. This is sometimes referred to as "K8s Secrets" mode.
• Using Secrets files: The Secrets Provider can generate initialization or credentials files for your application based on secrets retrieved from Conjur, and it can write those files to a volume that is shared with your application container. This is referred to as the Secrets Provider "Push to File" mode. For more information, see the Secrets Provider Push-to-File guide.

Deployment Modes

The Secrets Provider can be deployed into your Kubernetes cluster in one of two modes:

• As an init container: The Secrets Provider can be deployed as a Kubernetes init container for each of your application Pods that requires secrets to be retrieved from Conjur. This configuration allows you to employ Conjur policy that authorizes access to Conjur secrets on a per-application-Pod basis.

• As a standalone application container (Kubernetes Job): The Secrets Provider can be deployed as a separate, application container that runs to completion as part of a Kubernetes Job. In this mode, the Secrets Provider can support delivery of Conjur secrets to multiple application Pods. In this mode, you would use Conjur policy that authorizes access to Conjur secrets on a per-Secrets-Provider basis.

  The Secrets Provider Helm chart can be used to deploy the Secrets Provider in standalone application mode.

• As a sidecar to enable secrets rotation.

NOTE: If you are using the Secrets Provider "Push to file" mode, the Secrets Provider must be deployed as an init or sidecar container, since these modes makes use of shared volumes to deliver secrets to an application.

Supported Services

• Conjur Enterprise 11.1+

• Conjur Open Source v1.4.2+

Supported Platforms

• GKE

• K8s 1.11+

• Openshift v4.6-v4.8 (Conjur Enterprise only)

Using secrets-provider-for-k8s with Conjur Open Source

Are you using this project with Conjur Open Source? Then we strongly recommend choosing the version of this project to use from the latest Conjur OSS suite release. Conjur maintainers perform additional testing on the suite release versions to ensure compatibility. When possible, upgrade your Conjur version to match the latest suite release; when using integrations, choose the latest suite release that matches your Conjur version. For any questions, please contact us on Discourse.

Methods for Configuring CyberArk Secrets Provider

There are several methods available for configuring the CyberArk Secrets Provider:

• Using Pod Environment Variables: The Secrets Provider can be configured by setting environment variables in a Pod manifest. To see a description of the Secrets Provider environment variables, and an example manifest in the Set up Secrets Provider as an Init Container section of the Secrets Provider documentation (expand the collapsible section in Step 6 of this guide to see details).

• Using Pod Annotations: The Secrets Provider can be configured by setting Pod Annotations in a Pod manifest. For details on how Annotations can be used to configure the Secrets Provider, see the Secrets Provider Push-to-File guide.

• Using the Secrets Provider Helm chart (Standalone Application Mode Only) If you are using the Secrets Provider in standalone application mode, then you can configure the Secrets Provider by setting Helm chart values and deploying Secrets Provider using the Secrets Provider Helm chart.

Some notes about the different configuration methods:

1. For a setting that can be configured either by Pod Annotation or by environment variable, a Pod Annotation configuration takes precedence over the corresponding environment variable configuration.
2. If you are using the Secrets Provider in Push-to-File mode, then the Secrets Provider must be configured via Pod Annotations.
3. If you are using the Secrets Provider in Kubernetes Secrets mode, it is recommended that you use environment variable settings to configure the Secrets Provider.

Enabling Tracing

Tracing of CyberArk Secrets Provider for Kubernetes is available using the OpenTelemetry standard. Tracing is disabled by default. You can enable tracing using either Pod Annotations or environment variables. To enable traces appended to the init container's logs, add the annoation conjur.org/log-traces: true to the Pod manifest, or set the LOG_TRACES environment variable to true. To instead export the traces to a Jaeger server, use the following annotation: conjur.org/jaeger-collector-url: http://<jaeger-collector-host>/api/traces or use the JAEGER_COLLECTOR_URL environment variable. Traces will include errors to assist in troubleshooting.

Releases

The primary source of CyberArk Secrets Provider for Kubernetes releases is our Dockerhub.

When we release a version, we push the following images to Dockerhub:

1. Latest
2. Major.Minor.Build
3. Major.Minor
4. Major

We also push the Major.Minor.Build image to our Red Hat registry.

Builds

We push the following tags to Dockerhub:

Edge - on every successful main build an edge tag is pushed (cyberark/secrets-provider-for-k8s:edge).

Latest - on every release the latest tag will be updated (cyberark/secrets-provider-for-k8s:latest). This tag means the Secrets Provider for Kubernetes meets the stability criteria detailed in the following section.

Semver - on every release a Semver tag will be pushed (cyberark/secrets-provider-for-k8s:1.1.0). This tag means the Secrets Provider for Kubernetes meets the stability criteria detailed in the following section.

Stable release definition

The CyberArk Secrets Provider for Kubernetes is considered stable when it meets the core acceptance criteria:

• Documentation exists that clearly explains how to set up and use the provider and includes troubleshooting information to resolve common issues.
• A suite of tests exist that provides excellent code coverage and possible use cases.
• The CyberArk Secrets Provider for Kubernetes has had a security review and all known high and critical issues have been addressed. Any low or medium issues that have not been addressed have been logged in the GitHub issue backlog with a label of the form security/X
• The CyberArk Secrets Provider for Kubernetes is easy to setup.
• The CyberArk Secrets Provider for Kubernetes is clear about known limitations and bugs, if they exist.

Development

We welcome contributions of all kinds to CyberArk Secrets Provider for Kubernetes. For instructions on how to get started and descriptions of our development workflows, see our contributing guide.

Documentation

You can find official documentation on our site.

Community

Interested in checking out more of our open source projects? See our open source repository!

License

The CyberArk Secrets Provider for Kubernetes is licensed under the Apache License 2.0 - see LICENSE for more details.