Secrets provider for K8s/Openshift

[john.odon (John ODonnell)]

Hi @kumarsen! Thanks for your interest in Conjur & Secrets Provider.

1. The Secrets Provider process will be pulling the credentials from Conjur, and then updating the Kubernetes Secret, defined by the manifest pictured, with said credentials. Secrets Provider uses the conjur-map data field as a guide for which Conjur variables to fetch and populate the Secret with. The result will be something like this, where the keys in the data field are the same as the keys in the conjur-map:

   apiVersion: v1
   kind: Secret
   metadata:
     name: db-credentials
   type: Opaque
   data:
     username: <b64-encoded value of secrets/username from Conjur>
     password: <b64-encoded value of secrets/password from Conjur>
   stringData:
     conjur-map: |-
       username: secrets/username
       password: secrets/password
   

2. Yes, the Secrets Provider image in the Red Hat registry is maintained by CyberArk.

3. In step 3b, base64-encoded secret data from Conjur is written into the Kubernetes Secret data field. Security implications of using K8s Secrets for sensitive data are explained in K8s’ Secret documentation:

   Kubernetes Secrets are, by default, stored unencrypted in the API server’s underlying data store (etcd). Anyone with API access can retrieve or modify a Secret, and so can anyone with access to etcd. Additionally, anyone who is authorized to create a Pod in a namespace can use that access to read any Secret in that namespace; this includes indirect access such as the ability to create a Deployment.

   In order to safely use Secrets, take at least the following steps:

   1. Enable Encryption at Rest for Secrets.
   2. Enable or configure RBAC rules that restrict reading and writing the Secret. Be aware that secrets can be obtained implicitly by anyone with the permission to create a Pod.
   3. Where appropriate, also use mechanisms such as RBAC to limit which principals are allowed to create new Secrets or replace existing ones.

   More hardening strategies are outlined in the page’s section on Information security for Secrets, and Openshift offers similar guidance for encrypting secret data - check out their 3.11 documentation on Encrypting Data at Datastore Layer.

4. I can understand the confusion here - the docs should name these ConfigMaps a bit better. There are two different ConfigMaps in play:

   • conjur-configmap is created by the Conjur Config Cluster Prep Helm chart (step 5 to Configure and enable a Kubernetes Authenticator). This “Golden” ConfigMap is used as a reference for application namespaces in the same cluster. In the workflow outlined by the documentation, this ConfigMap is created in the cyberark-conjur namespace.
   • conjur-connect is created by the Conjur Config Namespace Prep Helm chart (step 1 to Prepare the application namespace). This ConfigMap contains connection information taken from the “Golden” ConfigMap, which it will provide to applications in its namespace.

   In the commands shown:

   • helm install namespace-prep ... needs to know the name and namespace of the “Golden” ConfigMap, in this case conjur-configmap and cyberark-conjur. This command will create a ConfigMap named conjur-connect in the application namespace.
   • helm install secrets-provider ... needs to know the name of the ConfigMap in its namespace, created by the Namespace Prep Helm chart - in this case conjur-connect.

   The commands shown are correct - just a bit too ambiguous

Feel free to respond with any more questions.

- John