RBAC Manager was designed to simplify authorization in Kubernetes. This is an operator that supports declarative configuration for RBAC with new custom resources. Instead of managing role bindings or service accounts directly, you can specify a desired state and RBAC Manager will make the necessary changes to achieve that state.
This project has three main goals:
- Provide a declarative approach to RBAC that is more approachable and scalable.
- Reduce the amount of configuration required for great auth.
- Enable automation of RBAC configuration updates with CI/CD.
We recommend installing rbac-manager in its own namespace and a simple release name:
helm repo add fairwinds-stable https://charts.fairwinds.com/stable helm install rbac-manager fairwinds-stable/rbac-manager --namespace rbac-manager
As of chart version 1.6.0 Kubernetes 1.16+, Helm 2.10+
Helm 3 will be made mandatory in the future.
Upgrading to Chart Version 1.0.0
The upgrade to version 1.0.0 of this chart removes support for installing RBAC Definitions as part of the chart values. This change was made to simplify CRD installation with Helm. We recommend installing RBAC Definitions separately from the chart.
For backwards compatibility with the chart originally included in the rbac-manager repository, we’ve removed the Helm
install-crd hook from this chart. Unfortunately as part of improving backwards compatibility with the chart in the rbac-manager repository, we have made it more difficult to upgrade from the inital versions of the charts here.
Some quirks in Helm make the upgrade process from 0.x of this chart to 1.x challenging due to the potential of the RBAC Definition CRD getting deleted. In most cases, reinstalling the chart will be the best path forward.
If either of the following apply and you are upgrading from an earlier version of the chart found in this repository, keep on reading:
- A momentary lapse in access granted by RBAC Definitions is unacceptable
- You’re using auth tokens from Service Accounts created by RBAC Manager
The following process has worked repeatedly for us to upgrade from an older version of this chart to 1.0.0. These steps worked with Helm and Tiller 2.12.3 for us, but due to the absurdity of this process, we can’t guarantee it will work for you.
- Install rbac-manager with chart that uses install-crd hook (email@example.com)
- Upgrade to rbac-manager chart that doesn’t use install-crd hook (firstname.lastname@example.org) - this upgrade fails but is important later
- Upgrade to original rbac-manager chart that uses install-crd hook (email@example.com) - this works
- Rollback to revision 2 - this fails
- Rollback to revision 2 - this works
In the above workflow, an RBAC Definition installed between revision 1 and 2 should persist through to revision 5. This process is admittedly quite strange, and in our testing the second rollback (step 5) is indeed required for this process to work.
||The image to run for rbac manager|
||The tag of the image to run|
||The image pullPolicy. Recommend not changing this|
||A resources block for the rbac-manager pods|
||The name of a priorityClass to use|
||Annotations to apply to the pods|
||Labels to apply to the pod|
||If true, a ServiceMonitor will be created for Prometheus|
||Annotations to apply to the serviceMonitor and headless service|
||The namespace to deploy the serviceMonitor into|
||How often to scrape the metrics endpoint|