consul-k8s
consul-k8s copied to clipboard
hashicorp
Configure user-provided service accounts for all Helm Chart components
In hashicorp/consul-helm#121 when adding PSP support there were some RBAC objects (ClusterRole, ClusterRoleBinding) added. If PSP support is disabled (through enablePodSecurityPolicies) the RBAC objects are still generated, even though the ClusterRoles end up functionally empty.
These inert RBAC objects are a problem in our environment where users do not have permissions to create RBAC rules. Given that the RBAC rules are currently only used to activate the pod security policies I'm curious if it would be OK to wrap them entirely in a conditional based on enablePodSecurityPolicies? Or if not perhaps we could add a separate conditional to disable RBAC generation?
Hi @jheiss,
We previously allowed RBAC to be optional in the chart and it seems reasonable to add it back as an option. We've generally operated on the assumption that Consul would be considered more of an infrastructure-managed entity that operates across a cluster. It sounds like you have a different use case and it would be great to hear a bit more about it if you're willing to share.
One thing to note about this-- we're adding support for Kubernetes as an identity provider in configuring ACLs. As part of this, service accounts will be used to help automatically configure ACL tokens for services. Not enabling RBAC within the chart may negatively impact the ability to make use of this feature. (Some in progress work on the feature if you're interested PR 5600 and PR 5640).
Hey there! The Consul team is looking for more feedback on the Consul Helm Chart. If any of you have 3 minutes, consider filling out our survey.
No, standard Kubernetes. We use RBAC and PSP to limit users to specific namespaces, and do not give them permission to set their own RBAC or PSP rules.
Responding to @adilyse's question from long ago that I somehow missed: Even if we wanted some team to run Consul for the whole company that team likely would not be the same team as our Kubernetes admin team and thus wouldn't have administrative privileges to change RBAC or PSP rules either. We would expect them to run Consul in their own namespace. Hypothetically we might give them special permission to scrape data out of the Kube API server for some or all namespaces, we've done that for a few teams where it seemed appropriate.
We have the same requirement for this as our company has very strict role/privilege control. We want to install consul only inside one namespace and we only have few privileges to that namespace.
We have the same requirement for this as our company has very strict role/privilege control. We want to install consul only inside one namespace and we only have few privileges to that namespace.
Since this ticket was opened we have modified some of our cluster roles to be roles instead. Are you still seeing issues installing? What features are you using of the helm chart?
We have the same requirement for this as our company has very strict role/privilege control. We want to install consul only inside one namespace and we only have few privileges to that namespace.
Since this ticket was opened we have modified some of our cluster roles to be roles instead. Are you still seeing issues installing? What features are you using of the helm chart?
Our k8s admin doesn't assign "rbac.authorization.k8s.io/v1" permssion to our deployer/developer, even inside its own namespace. So I am thinking whether we can use consul-helm without "rbac.authorization.k8s.io/v1" api permssion.
Our k8s admin doesn't assign "rbac.authorization.k8s.io/v1" permssion to our deployer/developer, even inside its own namespace. So I am thinking whether we can use consul-helm without "rbac.authorization.k8s.io/v1" api permssion.
One solution we could look into is allow user-provided service account for helm chart components. In that case, you would need to ask your cluster admin to create the necessary rbac permissions and then just provide those existing service accounts as values to the helm chart. Would that work for your use-case @CrisLi?
Our k8s admin doesn't assign "rbac.authorization.k8s.io/v1" permssion to our deployer/developer, even inside its own namespace. So I am thinking whether we can use consul-helm without "rbac.authorization.k8s.io/v1" api permssion.
One solution we could look into is allow user-provided service account for helm chart components. In that case, you would need to ask your cluster admin to create the necessary rbac permissions and then just provide those existing service accounts as values to the helm chart. Would that work for your use-case @CrisLi?
Yes, that would be a solution for my use-case.
We unfortunately have not had time to work on this and are open to community PRs. The recommendation suggested in https://github.com/hashicorp/consul-k8s/issues/683#issuecomment-726539962 seems like a good path forward here to support the use cases described in this issue.
