Openshift Conjur integration (Followers outside of the Openshift)

[kumarsen (kumar s)]

Hello Team - We are planning to integrate opeshift containers with conjur to fetch secrets. The followers are not deployed in Openshift and they are in standalone hosts.

1. Per my understanding based on the documentation - if the followers are outside the openshift/k8s clusters then, the only supported configuration is to use JWT based authn correct ?

2. I have a specific question on the below two possible ways to set up the apps.

2.1 If we are using the k8s authentication client then does the access token gets stored in plain text (even base 64 encoded) in the shared volume - /run/conjur ? I understand the token has a TTL of 8 mins by default, how can one protect the short lived token that is stored on the volume ?

In order for the container to retrieve secrets, we can use REST API or summon by using the access token stored in the volume mount ?

2.2 If we are going with ‘secrets provider’ route - which is more secure - Push to file or K8s mapped secrets ?

For the k8s mapped secrets then the configMap is configured as below ?
trying to understand what “conjur-map: | -” does.

In addition for the push-to file method, is it secure to have the credentials.yaml in hard coded format ?

Thanks,
Kumar

[john.odon (John ODonnell)]

Hi @kumarsen!

1. If the followers are outside the openshift/k8s clusters then the only supported configuration is to use JWT based authn correct?

   This is not correct. Both certificate- and JWT-based authn are supported when Followers are deployed outside the Openshift/K8s cluster. From the section describing Set up options:

   

   If there is a section of the docs that gives you this impression, please share.

2. Does the access token get stored in plain text (even base 64 encoded) in the shared volume? I understand the token has a TTL of 8 mins by default, how can one protect the short lived token that is stored on that volume?

   The access token is stored in plain text in the shared volume. If you follow the official CyberArk documentation, the shared volumes containing secrets use the emptyDir volume type, which writes data to memory instead of disk, and is cleared when a node reboots. It’s important to note that protecting secret data in your K8s or Openshift cluster is also a matter of your cluster hardening strategy. Conjur’s K8s integrations, like the Authenticator Client and Secrets Provider, need to work in tandem with cluster security best-practices.

   we can use REST API or summon by using the access token stored in the volume mount?

   Yup! The solutions you’re looking for are listed here.

   If we are going with secrets-provider route - which is more secure - Push to file or K8s mapped secrets?

   So, there are two methods by which K8s Secrets can be used in an application pod - using Secrets as environment variables or using Secrets as volume-mounted files.

   That said, you should avoid using environment variables for secret data.

   From the perspective of an application container, using Secrets Provider in Push-to-File mode is essentially equivalent to storing secret data in K8s Secrets, and using them as volume-mounted files. We’ve just cut out the middle-man, and in doing so avoid some of the security implications of K8s Secrets, like being written to disk unencrypted by default.

   Edit: A recently release CNCF security whitepaper prefers in-memory shared volumes to environment variables, supporting Push-to-File’s approach.

   For the k8s mapped secrets then the configMap is configured as below? trying to understand what “conjur-map: |-” does.

   I might’ve answered this in response to another post you made.

   For the push-to-file method, is it secure to have the credentials.yaml in hard coded format?

   I think this question is similar to your question about the base64 encoded access token being stored in a shared volume mount, so the answer is the same: all of our integrations should work in tandem with cluster security best-practices. Secret data in a shared volume, while more secure than a K8s Secret, is only as a secure as your cluster hardening strategy.

   Additionally, Secrets Provider allows for customizing permissions on secret files. See the configuration table for more on this option.