We are looking to use Conjur+OSS with Secretless broker for the secret managemetn for our jupyterhub ML platform. We want to store those AWS credentials of different users in Conjur, and then use secretless broker to retrieve and connect to AWS. I can make the flow works with a single user by using API key-based authentication.
However, this doesn’t sound good enough. We prefer a user who’s authenticated with jupyterhub can also be known by Conjur (or secreteless broker). When making connection to AWS, secretless+conjur knows how to retrieve corresponding credential for that user.
Hi @iampolo. I think it depends on how a user is authenticated to jupyterhub. The authenticators supported by Conjur are documented at Authentication. Please have a look and see if one of these might meet your requirements. Please also provide some context around how authentication works in jupyterhub to allow us to better determine if there’s an authenticator that meets your requirements.
Hi @kumbirai,
Thank you for your reply. Our Jupyterhub runs in Openshift. Users are authenticated with github idp configured with Openshift. I think the Conjur authn-k8s might be a good fit.
The way Jupyterhub works is it spawns a new pod whenever a user wants to work on a jupyter NB. This pod has only default service account, it has no deployment obj., and all these pods are in a shared namespace. I think I can only use pod name as the identity. Do you have any comment or other suggestion?
Regarding the Conjur-OSS setup as well as authn-k8s setup in OCP, do you have any example, or tutorials? Your help could save lots of my research and experiment time.
Btw, the main reason we choose Conjur is to use its Secretless broker backed by Conjur vault.
Hi @kumbirai,
What is the difference of the policies defined in the following two links? DAP Policies and the policy tutorials introduced here.
Basically, are the policies defined in Conjur-OSS and DAP interchangable?
Hi @iampolo. I think yes, authn-k8s might be a good fit. Here are the list of supported identity formats Application Identity in OpenShift/Kubernetes. Pod name could be used but I anticipate the challenge of pod names not being known ahead of time, and therefore that workflow might require some automated enrolment process that, perhaps at the time the pod name becomes, would craft a host with the pod name annotation and grant it the correct permissions. A simpler approach that allows the setting permissions prior to pod creation is available when the source of identity is known ahead of time.
Generally speaking I think the policy language is interchangeable. However, there are features in Conjur Enterprise that do not exist in OSS. For example, the link you shared to DAP policies exists under the CyberArk Vault Synchronizer section which concerns an enterprise-only feature. So though the policy language used is the same the concepts of Safes etc. have no meaning in OSS.