Supporting the Latest Standards with Validated Patterns

Definitive explanations of what OLMv1 is can be found here: Announcing OLM v1: Next-Generation Operator Lifecycle Management. Detailed information on how to create ClusterExtension objects can be found here: Manage operators as ClusterExtensions with OLM v1.

OLMv1 introduces a completely new Kubernetes Kind, the ClusterExtension, which functions somewhat differently than the Subscription object that previous versions of OLM used. Further, OLMv1 requires the explicit use of a service account with which to install the operator bundle. OLMv1 is fairly restrictive in not allowing several previously common methods of declaring version constraints, but over time we expect more operator bundles will support being installed via OLMv1.

OLMv1 objects are created by passing entries through the Subscriptions object. Each subscription may be an OLMv0 or OLMv1 object. The determination on which type of object to create is based on the presence of OLMv1 specific fields. If the object for the subscription contains a "channels", "upgradeConstraintPolicy" or "serviceAccount" key, an OLMv1 ClusterExtension object will be created. Otherwise, the framework will create an OLMv0 Subscription. Existing code will continue to function as it has.

Here is an example of a subscription object that will create an OLMv1 ClusterExtension:

The chart sees the "channels" key and the "serviceAccountName" key and knows that it should create an OLMv1 object based on that. The name becomes the OLMv1 PackageName. You may also specify a "version" key to pin the subscription to a specific version or range as described here. If you need it, the chart also understands and uses the "upgradeConstraintPolicy" key.

Additionally, OLMv1 allows multiple channels to be added, so they key "channels" takes an array of channel names.

The final difference is the serviceAccountName. OLMv1 now requires a service account name to install each operator. Before, the Validated Patterns framework did not have a mechanism to install serviceAccounts, roles, or role bindings early enough for them to be used to install operators. Several patterns had their own structures for adding these objects, but they were private to the patterns, or else not especially flexible and could not be changed without effectively re-writing them. Since that chart had been published under the name "rbac" in our charts repository, we wrote a new chart that could be used by clustergroup, and could be included as a dependency in other charts as well.

The new vp-rbac chart is designed to provision serviceAccounts, roles, clusterRoles, and rolebindings. It was developed primarily to meet the needs of clustergroup for adding serviceAccounts to install operators with fine-grained access controls, but can be used for other serviceAccounts scenarios as well.

The (simplest, though perhaps not the most secure) structure needed to install quay looks like this:

The key ('quay-sa' in this case) becomes the name of the serviceAccount, and the namespace key is required. Rolebindings can be created for roles or clusterRoles; in this case we bind quay-sa to the (pre-existing) cluster-admin clusterRole. Rolebindings are always part of the serviceAccount structure for this chart.

The chart also supports creating roles and clusterRoles, if you need to define custom ones. Roles and clusterRoles support multiple rules. Each rule may specify apiGroups, resources, and verbs. If a rule omits one of these keys, they each have defaults: apiGroups defaults to [ "'*'" ] (which includes the empty or core apiGroup); resources similarly defaults to [ "'*'" ]; verbs defaults to [ 'get', 'list', 'watch' ] (that is, "read-only" permissions).

Here is a more complete example of what can be done with the vp-rbac structure:

This structure allows the creation of structures as fine-grained as you may need, and also makes it straightforward to create a serviceAccount with admin just to experiment or as a proof-of-concept if you do not know exactly what permissions are actually needed.

You can add vp-rbac to your charts by declaring it as a dependency to your chart, like this (in Chart.yaml):

We enhanced our chart-building pipeline to be able to resolve and include chart dependencies for the charts that we publish in our chart repository.

We may replace some of the RBACs that we create in the patterns framework with the vp-rbac chart, but we do not plan to do this for all of our charts as this might break backwards compatibility in some cases.

We are excited to offer support for OLMv1 fairly early in its adoption cycle; please feel free to give it a try! If you encounter any issues with the OLMv1 feature in clustergroup, please report them here. Any issues witht the vp-rbac chart can be reported here.