Hello team, we are planning to integrate K8s and Openshift with Conjur enterprise (v 12.4) and we are planning to use secrets provider (Application container) as a secret retrieval method. We have a few questions as a part of the integration.
- Regarding the k8s secrets, how is the configmap conjur-map as given below is pulling the credentials? I don’t see a conjurmap with the name “conjur-map” created anywhere, just want to understand what that ‘conjur-map’ is ?
- While installing the secret provider for k8s using the helm chart with the default ‘values.yml’ file, i see it shows only the docker image, for openshift deployments i do see an image in redhat catalogs - “registry.connect.redhat.com/cyberark/secrets-provider-for-k8s:latest” ,just wanted to make sure if that’s the correct one.
- From the below screenshot, what does step 3.b mean ? Does it mean that the secret value will be visible (even though encoded) ? Or does it store only in memory ?
- In the last step of the configuration (below), the configMap value is “cyberark-conjur” that was created during the “Prepare the application namespace” correct ? in the below screenshot it is given as “conjur-connect” instead of “cyberark-conjur” (just wanted to make sure my understanding is right)
Thanks a lot,
Hi @kumarsen! Thanks for your interest in Conjur & Secrets Provider.
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
username: <b64-encoded value of secrets/username from Conjur>
password: <b64-encoded value of secrets/password from Conjur>
Yes, the Secrets Provider image in the Red Hat registry is maintained by CyberArk.
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:
Enable Encryption at Rest for Secrets.
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.
- 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.
I can understand the confusion here - the docs should name these ConfigMaps a bit better. There are two different ConfigMaps in play:
In the commands shown:
helm install namespace-prep ... needs to know the name and namespace of the “Golden” ConfigMap, in this case
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
The commands shown are correct - just a bit too ambiguous
Feel free to respond with any more questions.
Hey @john.odon - Sorry for the delay. Thanks much for the help. Appreciate all your responses.
For 3., What is the benefit by implementing Conjur if the secrets are updated in encoded string anyways? This can be achieved even without using conjur correct ?
Sorry our leadership wants to know what’s the real security benefit from using conjur in this scenario.
@kumarsen base64 encoding is not for the secrets itself but the variables named would need to base64 encoded.
@sjohnkennedy - The variable names should be in plaintext based on the data block as given below ?
Sorry i am confused with your statement “but the variables named would need to base64 encoded.” - As far as I understand, the variables will be plain text and Conjur will update the secrets in kubernetes as a base64 encoding password. Isn’t that the case ?