Giters

IBM / operand-deployment-lifecycle-manager

Managing the lifecycle for a group of operands

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

How to auto-setup RBAC when create OperandRequest in a namespace other than the default one

morningspace opened this issue · comments

commented

/kind bug

What steps did you take and what happened:
By following the docs, all operators and operands along w/ the OperandRequest objects will be deployed in the odlm namespace.

I was trying to install those stuff to another namespace, then figured out that the below settings need to be modified at first:

apiVersion: v1
data:
  namespaces: odlm,default
kind: ConfigMap
metadata:
  name: odlm-scope
  namespace: odlm

As above, I append a second namespace (default) after odlm. Apart from that, I found that I have to manually apply some RBAC settings, otherwise, ODLM will report error, such as:

E0717 09:13:32.918450       1 reflector.go:138] pkg/mod/k8s.io/client-go@v0.20.5/tools/cache/reflector.go:167: Failed to watch *v1alpha1.Subscription: failed to list *v1alpha1.Subscription: subscriptions.operators.coreos.com is forbidden: User "system:serviceaccount:odlm:operand-deployment-lifecycle-manager" cannot list resource "subscriptions" in API group "operators.coreos.com" in the namespace "default"

What did you expect to happen:

Is there a way to setup RBAC automatically when create OperandRequest in a namespace other than the default one?

Environment:

  • ODLM version: latest
  • Minikube/KIND/OCP version: kind v0.12.0-alpha+718ede73045ce3
  • Kubernetes version: (use kubectl version): v1.21.2
  • OS (e.g. from /etc/os-release): RHEL
commented

Hi @morningspace

If we directly deploy ODLM by following this doc here, ODLM does not have enough permission to automatically extend its RBAC to other namespaces.

There are two ways to do that.

  1. Install the foundational services operator including ODLM by following this docs here on OCP. those operators will coordinate with each other to manage the RBAC. Therefore, when you create ODLM's resources in other namespace. It will extend the permission of ODLM to that specific namespace.

  2. Still deploy ODLM alone on Kubernetes, but this time we will manually grant the ODLM the cluster permission to manage all the resources. I will update the docs here later, indicating how to deploy ODLM in cluster scope which could easily deploy resources in other namespace by ODLM.