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[bot]]

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

[ecordell]

As Daniel described, there is not a reasonable way to lock down OLM's permissions as deployed today.

There are mechanisms within OLM (OperatorGroup.spec.serviceAccount) to lock down what OLM can do in certain contexts, and OLM can be deployed with a more restrictive service account if desired, but that is not a standard deployment scenario that makes sense to support (because, as Daniel mentioned, it can arbitrarily conflict with some desired operator installation).

I think there are some interesting approaches we could look at:

• A tool that can calculate a set of RBAC that can install everything in a certain catalog but nothing else. OLM can then be configured / deployed with the minimum permission to install content for a specific catalog.
• Separate tooling for offline resolution and installation, so that content is selected for install offline and created on a cluster via some user's credentials. In this case, the part of olm that needs the high permission (catalog-operator) can be omitted from a cluster entirely).

But those are larger and separate efforts.

[pamelachristie]

@ecordell Would the community at least be able to support https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection? That would help mitigate the problem in cases where the pod was temporarily compromised.

[dmesser]

@pamelachristie Could you lay out how ideally OLM would use the projection feature?

[pamelachristie]

Ideally OLM would use the feature as documented by Kubernetes. The pod could optionally use a projected token volume mount to authenticate to the Kubernetes API server. This would minimize the attack window opened if a pod is temporarily compromised since a stolen token would eventually expire.

[dmesser]

@pamelachristie Got it, agreed this is a good suggestion.

[LalatenduMohanty]

The way OLM V0 is designed it expect cluster-admin and without it , it will fail. However V1 is getting rewritten to solve this use-case where the cluster extension (i.e. operator) author can provide the service account for the operator. cc @kevinrizza @joelanford in-case you guys want to add more information.