Table of Contents
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
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:
- 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.
- If you are using the Secrets Provider in Push-to-File mode, then the
Secrets Provider must be configured via Pod Annotations.
- 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:
- Latest
- Major.Minor.Build
- Major.Minor
- 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.
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.