Access Control
There are currently two modes of access control supported by kro, if you install through the Helm chart:
-
unrestricted -
aggregation
The mode is selected with a values property rbac.mode, and defaults to unrestricted.
unrestricted Access
In the unrestricted access mode, the chart includes a ClusterRole granting
kro full control to every resource type in your cluster. This can be
useful for experimenting in a test environment, where access control is not
necessary, but is not recommended in a production environment.
In this mode, anyone with access to create ResourceGraphDefinition resources,
effectively also has admin access to the cluster.
aggregation Access
In the aggregation access mode, the chart includes an aggregated ClusterRole
which dynamically includes all rules from all ClusterRoles that have the label
rbac.kro.run/aggregate-to-controller: "true".
There is a very minimal set of permissions provisioned by the chart itself, just
enough to let kro run at all: full permissions for ResourceGraphDefinitions
and its subresources, and full permissions for CustomResourceDefinitions as
kro will create them in response to the existence of an RGD.
However, this does not automatically set up permissions for kro to actually reconcile those generated CRDs! In other words, when using this mode, you will need to provision additional access for kro for every new resource type you define.
Example
If you want to create a ResourceGraphDefinition that specifies a new resource
type with kind: Foo, and where the graph includes an apps/v1/Deployment and
a v1/ConfigMap, you will need to create the following ClusterRole to ensure
kro has enough access to reconcile your resources:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
labels:
rbac.kro.run/aggregate-to-controller: "true"
name: kro:controller:foos
rules:
- apiGroups:
- kro.run
resources:
- foos
verbs:
- "*"
- apiGroups:
- apps
resources:
- deployments
verbs:
- "*"
- apiGroups:
- ""
resources:
- configmaps
verbs:
- "*"