Scope down capi-operator-manager-role ClusterRole Permissions about cluster-api-operator HOT 5 CLOSED

Hello @keskanatala! Unfortunately, there is a reason behind granting such broad permissions to our operator. As you may be aware, each cluster API provider has a unique set of Custom Resource Definitions (CRDs) - such as AWSMachineTemplates in CAPA, AzureManagedControlPlane in CAPZ, and so on. Additionally, these providers have their own RBAC permissions for their respective CRDs. To install these RBAC permissions, our operator must also has them; otherwise, we encounter a user is attempting to grant RBAC permissions not currently held error. This list of permissions is constantly evolving and cannot be predetermined or statically set, hence necessitating admin privileges for the operator.

If you have security concerns, there is a workaround. Rather than creating a ClusterRoleBinding, you can create a RoleBinding and specifically choose the namespaces where you install your providers. For example, if you want to install CAPA in capa-system namespace, just delete the permissive ClusterRoleBinding and apply this

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  labels:
    clusterctl.cluster.x-k8s.io/core: capi-operator
  name: capi-operator-manager-rolebinding
  namespace: capa-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: capi-operator-manager-role
subjects:
- kind: ServiceAccount
  name: default
  namespace: capi-operator-system

After that operator will have admin permissions in a particular namespace rather then in the whole cluster.

I'm going to write a small document to describe this process in details.

from cluster-api-operator.

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

from cluster-api-operator.

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

from cluster-api-operator.

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

from cluster-api-operator.

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

from cluster-api-operator.