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)
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 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
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 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.
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
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.
@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 ?
I am using secrets-provider-for-k8s and trying to populate the K8 secret, but I am getting the following error
provide_conjur_secrets.go:335: CSPFK034E Failed to retrieve DAP/Conjur secrets. Reason: Conjur response is not Base64-encoded. The Conjur version may not be compatible with this function - try using RetrieveBatchSecrets instead.
Hi @senthilredhat - it’s likely you’re using versions of Conjur and Secrets Provider that are incompatible.
Starting in Conjur v1.11.2, batch secret retrieval requests with an Accept: base64 Header return base64 encoded secret values.
Starting in Secrets Provider v1.5.0, secret batches are exclusively retrieved as base64 encoded to enable providing binary secret values.
It looks like you’re using a newer Secrets Provider version (>= v1.5.0) than Conjur version (< v1.11.2). Using the latest of each should resolve this issue.
