This is an RFE to ask Red Hat for software to check operator manifest files prior to deployment for inappropriate permissions. Two types of checks are described

1) Absolute permission checks

2) Relative permission checks (changes to permissions in “N” version of operator compared with previous (“N–1”) version.

Absolute permission checks

The is needed when  working on pipeline for building operators from operator-sdk compliant source code, along with building the bundles of manifest files and catalog index images needed to allow Operator Lifecycle Manager (olm) to deploy that operator.

The permissions granted to the operator are defined in the operator-sdk compliant source code provided by the developer, and will be incorporated into the deployment bundle in the catalog index image used by olm. Olm runs with cluster admin permissions and will deploy whatever it finds referenced in the bundle for the operator in the catalog index image it is using. Hence, an developer could grant their operator very powerful and inappropriate permissions, and olm would just deploy it.

Hence, it is essential that the operator deployment manifest files are checked BEFORE DEPLOYMENT for any inappropriate entries. Ideally, these checks should take place in the operator & bundle build pipeline, so that:

1) Feedback can be given to the developer early in the development lifecycle when inappropriate permissions are detected.

2) Builds for production usage can be aborted before the bundle is added to any catalog image.

A few examples (definitely not a comprehensive list) of checks that need to be made against the operator manifest file include checking the operator CSV file for the following (bad) configurations:

• operator image is running out of an uncontrolled development repository
• apiGroups, resources and verbs specifications with wildcards
• the ability to list secrets (especially as a cluster role)
• the ability to impersonate users, groups and serviceaccounts. Impersonation should only be used for debugging purposes, and should not be built into an operator.
• Containers template specs with securityContext with:
o allowPrivilegeEscalation: true
o Privileged: true
• apiGroup rules that are exactly the same as the operator-sdk default (which is very open, and includes clusterRoles). This might suggest that the developer has not even attempted to fine-tuned the rbac to meet the actual operator needs.
• Check for the creation of a new SCC (kind: SecurityContextConstraints), although this might be being done in a separate manifest file to the CSV.

The pipeline owner should be able to adjust if failure of a given check raises just an alert (for info) or blocks the operator build from continuing. For example, use of wildcards for resources or verbs, or referencing an image out of an uncontrolled development repository would be a block. In contrast, the alert that apiGroup rules that are exactly the same as the operator-sdk default would just be an alert.

The checks need to cover any operator bundle manifest files that grant permissions, as the setup of those permissions are not limited to the operator CSV file.

Relative permission checks

No software can determine what permissions an arbitrary operator needs, as that is totally dependent on what its role is. Some infrastructure operators will legitimately require powerful cluster permission across all namespaces. Other should only have limited permissions of a single namespace. Hence, a human review of permissions will be needed for the INITIAL deployment of a new operator via olm.

However, we don’t want to repeat the human review for every minor update to that operator. Instead, we need automation that can compare the bundle for the new (call is “N”) version of the operator and compare it against the previous approved version (“N – 1”) for any additional permissions that the developer may have put in. This check would again need to take place WITHIN the operator & bundle build pipeline (i.e. prior to deployment) so that if any “N version” deployment manifest files are detected that have additional unapproved permissions compared with the “N – 1” bundle (stored in the catalog image), then the build can be aborted.

The ability would be needed (e.g. via a whitelist) to permit an approved change to permissions in bundle files to complete a build in the pipeline.