Security concern OLM ClusterRole has significant cluster privileges

[kramvan1]

Bug Report

The OLM operator pod has significant cluster privileges that could lead to privileged escalation. In particular, the pod has access to all resource. As a result, hacking the pod provides an easy path to privileged escalation.

# Source: original/0000_50_olm_01-olm-operator.serviceaccount.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: system:controller:operator-lifecycle-manager
  labels:
    addonmanager.kubernetes.io/mode: Reconcile
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]
- nonResourceURLs: ["*"]
  verbs: ["*"]

What did you do?
Review the OLM ClusterRoles for security

What did you expect to see?

A smaller scope of resources and verbs allowed in the OLM ClusterRole.

What did you see instead? Under which circumstances?

All resources and verbs are allowed.

Environment

• operator-lifecycle-manager version: 0.15.1

• Kubernetes version information: n/a

• Kubernetes cluster kind:

Possible Solution

Change ClusterRole to only include resources and verbs that are actually needed.

Additional context

[exdx]

It would be ideal to limit the scope of the OLM ClusterRole, for security reasons as you mentioned, but as OLM grows and is responsible for managing more and more resources it becomes tricky to provide an exact list of resources and verbs. We are looking to the future where OLM will support all arbitrary resources provided in operator bundles.

That being said, security is a top priority and we will looking into how to potentially address this concern.

[kramvan1]

@exdx Thx for the update, yes this is an interesting use case to address.

[pamelachristie]

@exdx Has any progress been made on addressing this?

[exdx]

There has not but this would be a great topic to bring up in the OLM working group meeting, see
https://github.com/operator-framework/community/tree/master/wg-olm for the meeting links. There is a meeting scheduled for this Thursday @pamelachristie

[pamelachristie]

Any progress on this?

[exdx]

We could discuss this up during our upstream feature planning meeting, there is one one tomorrow morning at 10AM EST.

I recommend opening a ticket on the Openshift RFE Jira board (its publicly accessible) under OLM and we can prioritize it from there. https://issues.redhat.com/projects/RFE/issues

cc @dmesser

[dmesser]

@kramvan1 OLM installs Operators on behalf of the user. The upside is that a user does not have to have all privileges that the Operator needs, the downside is that OLM needs to have those.
Since OLM will create the RBAC for all Operators under management, it is impractical to scope it down since it would require that we predict what APIs an Operator might need access to. OLM cannot grant RBAC on API it does not have permissions to.

[stale]

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.

[pamelachristie]

bump