Closed ismarc closed 5 years ago
More info: "Single instance of OSS that can communicate with a k8s authn client deployed to a pod"
Expectation (from the info we have right now) is that this mTLS is intra-cluster rather than the larger inter-cluster setup.
@ismarc What is the experience for getting a secret to an app deployed in GCP after the steps outlined above? In other words, these steps describe getting Conjur running on GCP, but how does one use it to go end-to-end?
This is now waiting on Google to do the final "release" to marketplace.
From them:
Great news! Thanks for the update. I will keep you posted on the progress.
Regards,
Jeevan
This is released now: https://console.cloud.google.com/marketplace/details/cyberark/conjur-open-source has tag v1.3
Can we mark all the sub stories complete and push this to Released now? @sgnn7 @ismarc @garkler
When deployed into Google Cloud Platform via the Google Cloud Marketplace, the Conjur OSS helm chart will expose a mechanism to enable any authenticator(s) and run any additional services required for the authenticators to function properly.
When deploying from Google Cloud Marketplace:
Conjur will then be deployed into the cluster and namespace selected with the app instance name provided. It will use the supplied Postgres URL (or generated one for a launched Postgres instance) with the provided authenticators enabled. All additional services necessary (mTLS support for authn-k8s, etc.) to support the authenticators will be provided.
The assumption is that it is a single OSS instance communicating with an authn-k8s client (via sidecar or init container) deployed to a pod using service accounts. mTLS is assumed to be intra-cluster rather than the larger inter-cluster setup.
A scripted version of the client process is available at https://github.com/conjurdemos/kubernetes-conjur-demo and is expected to work with the above deployed Conjur OSS instance.
When deploying a client:
Right now, there is no way to enable different authenticators and even if enabled additional support is needed for the authenticators (such as mTLS for the kubernetes authenticator). This limits the capabilities and benefit of using Conjur. All authenticators should be usable when deployed via the helm chart.
Specific support is needed for kubernetes, it needs to support authn-k8s authentication within the same cluster between the Conjur OSS (master) instance and clients (conjur-authn-k8s-client) sidecar or init container using service accounts.
Fig 1
Fig 2