operator-lifecycle-manager

operator-lifecycle-manager copied to clipboard

Bug Report

What did you do?

I installed the olm in a k8s cluster. Then I created an OperatorGroup specifying only the kfox namespace in the kfox namespace. I then subscribed to the elastic operator naming the subscription 'foo'

I noticed clusterroles are on the cluster: +foo-admin +foo-edit +foo-view They are labeled:

  labels:
    olm.owner: foo
    olm.owner.kind: OperatorGroup
    olm.owner.namespace: kfox

I believe this will run into problems if there is a second subscription named 'foo' in another namespace

What did you expect to see?

No non-namespaced roles.

Environment

• operator-lifecycle-manager version:

image: quay.io/operator-framework/olm@sha256:73d60e4f2adbc70ed8df93245fb2d83c9e0062489a22110d897b83c21918e101

• Kubernetes version information:

Client Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.0", GitCommit:"70132b0f130acc0bed193d9ba59dd186f0e634cf", GitTreeState:"clean", BuildDate:"2019-12-07T21:20:10Z", GoVersion:"go1.13.4", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.0", GitCommit:"70132b0f130acc0bed193d9ba59dd186f0e634cf", GitTreeState:"clean", BuildDate:"2019-12-07T21:12:17Z", GoVersion:"go1.13.4", Compiler:"gc", Platform:"linux/amd64"}

• Kubernetes cluster kind:

minikube

Hi @kfox1111, thanks for taking the time to report this issue.

A set of ClusterRoles is generated for each operator-provided API (i.e. CRDs and APIServices). Each OperatorGroup also gets its own set of ClusterRoles, to aggregate (https://kubernetes.io/docs/reference/access-authn-authz/rbac/#aggregated-clusterroles) the set of roles provided by operators that are members of the OperatorGroup.

I believe that you're seeing these per-OperatorGroup roles, which would be expected if there is an OperatorGroup "foo" in your cluster's "kfox" namespace. This does look like a problem for clusters with multiple OperatorGroups sharing the same name.

That makes sense. So its basically missing the namespace name in the generated name clusterrole name?

That makes sense. So its basically missing the namespace name in the generated name clusterrole name?

Yes, that would work. The name is generated here: https://github.com/operator-framework/operator-lifecycle-manager/blob/d921b442f104fdf7d5fae5aacb56d6038860e785/pkg/controller/operators/olm/operatorgroup.go#L887 and changing that should be straightforward, but a fix for this issue will also need to take care of migrating any pre-existing roles.

Yeah, that looks about right. Guessing there is some code to make a RoleBinding pointing at it somewhere as well.

Any updates?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contribution. For more help on your issue, check out the olm-dev channel on the kubernetes slack [1] and the OLM Dev Working Group [2] [1] https://kubernetes.slack.com/archives/C0181L6JYQ2 [2] https://github.com/operator-framework/community#operator-lifecycle-manager-wg

This issue has been automatically closed because it has not had any recent activity. Thank you for your contribution.

This should be unclosed. I think it is still an issue.

No problem -- we just implemented a new stalebot functionality so that we can better triage issues that affect users versus which are actually stale.

I encountered this problem cause I was naming my OperatorGroups cluster (since they target all namespaces it seemed reasonable!) and they were overwriting the cluster-admin ClusterRole. It took me quite a few hours to understand the issue! Including the namespace in the ClusterRole's name would've helped.