I’ve got a few questions related to the architecture around K8s deployments: Architecture
How scalable is that? The architecture page reads that the followers can be scaled horizontally. What are the criteria?
How often do the Conjur followers in Kubernetes/Openshift refresh the secrets?
Can application teams manage their own Conjur namespace? Would the readonly Postgres DB contain all secrets available in master or are the secrets in the readonly namespace restricted to secrets under a Conjur policy?
How scalable is that? The architecture page reads that the followers can be scaled horizontally. What are the criteria?
As long as you have seed-fetching configured so that Follower pods can self-initialize, you can use the built-in deployment scaling in OCP. Follower configuration and startup can take anywhere from 30 seconds to several minutes depending on the number of secrets that are needed to be replicated from the Leader. I’ve never setup autoscaling rules (e.g. monitoring CPU load), I’ve just used it for the ability to add more replicas via the UI (up arrow for more, down arrow for less).
How often do the Conjur followers in Kubernetes/Openshift refresh the secrets?
The Conjur Leader replicates any changes made to it to Followers within a few hundred milliseconds.
a. Can application teams manage their own Conjur namespace?
Yes, we have reference policy models for exactly this.
b. Would the readonly Postgres DB contain all secrets available in master or are the secrets in the readonly namespace restricted to secrets under a Conjur policy?
All Followers are equal by design and contain a full encrypted copy of the Leader’s contents. The goal of that is so an app can connect to any Follower to get its secrets, but only the secrets the app is allowed to access. This also allows Followers to run behind load balancers without requiring any particular affinity rules, be swapped out without regard to their contents, and other aspects that ease administration of the solution.
Thanks Jody. Good to hear that it’s permitted for the development teams to run their own followers, but I feel uneasy that the followers they deploy would have a full copy of leader’s database which would may contain a lot more sensitive data
Well, you could always run separate Conjur clusters. We also support syncing multiple Conjur clusters from one CyberArk vault. So you can sync separate safes to different clusters (e.g. Dev safes to Dev cluster, Prod safes to Prod cluster).
Thanks Jody. How do you mean?
We run two separate Conjur clusters (one for prod and one for dev). A number of development teams in the company are getting interested in Conjur’s Kubernetes authenticator, and some of those teams self-manage their own Kubernetes cluster instead of using a centralised solution.
According to your response and the architecture diagram in my original post, I understand that those teams are required to deploy a new Kubernetes namespace for a Conjur follower, which would contain a full copy of the secrets database (even though it might be encrypted). I would like to understand a more secure workflow (if it exists) in which the application teams would not be in possession of either encrypted or plain-text Conjur database
Oh, gotcha. It’s not required to run Followers in the cluster, they can run outside of it on an isolated server. As long as they can call the K8s cluster API, they can authenticate pods in the cluster.
I don’t think it’s documented. You just start a Follower outside K8s, and initialize the K8s API variables and authenticator endpoint as you would if the Follower were in K8s. You can’t do self-initialization (AKA seed fetching), but it works just fine. Here’s how one of my older POC setup scripts does it: