diff --git a/content/blog/2025-08-11-olmv1-support-and-chart-dependencies.adoc b/content/blog/2025-08-11-olmv1-support-and-chart-dependencies.adoc new file mode 100644 index 000000000..832f65854 --- /dev/null +++ b/content/blog/2025-08-11-olmv1-support-and-chart-dependencies.adoc @@ -0,0 +1,174 @@ +--- + date: 2025-08-11 + title: Supporting the Latest Standards with Validated Patterns + summary: This post introduces how the Validated Patterns framework supports OLMv1, the new operator packaging standard + author: Martin Jackson + blog_tags: + - patterns + - announce +--- +:toc: +:imagesdir: /images + +Open Source Technology is always evolving, and we need to be prepared to evolve with it. In OpenShift 4.18, Red Hat +promoted the new OLMv1 packaging standard to General Availability. OLM is the Operator Lifecycle Manager, a vital +component of OpenShift. Users generally do not interact with OLM as such, but they are familiar with how OpenShift +offers Operators to install on clusters and OperatorHub - all of the operators advertized there are offered as OLM +packages. + +Up until this point, Validated Patterns have only supported installation via OLMv0. OLMv1 uses the same packaging +format, but places some restrictions on what the bundles can and cannot do. Further, OLMv1 requires a serviceAccount +to explicitly be named to install the bundle. This required changes to one of the framework's key charts, and that in +turn led to changes with how we manage our chart publication pipeline. This blog post will cover three topics: + +* Support for OLMv1 objects (ClusterExtensions) in the Validated Patterns Framework +* Using the new vp-rbac chart with Validated Patterns +* How our chart building pipeline had to change + +Please note that all of these changes are effective as of the publication of clustergroup chart version 0.9.30, so any +new installation of any publicly maintained Validated Pattern after August 8, 2025 will be able to make use of these +new features. + +== Support for OLMv1 (ClusterExtensions) + +Definitive explanations of what OLMv1 is can be found here: link:https://www.redhat.com/en/blog/announcing-olm-v1-next-generation-operator-lifecycle-management[Announcing OLM v1: Next-Generation Operator Lifecycle Management]. Detailed +information on how to create ClusterExtension objects can be found here: link:https://developers.redhat.com/articles/2025/06/02/manage-operators-clusterextensions-olm-v1[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: + +[source,yaml] +---- +--- + subscriptions: + quay-operator: + name: quay-operator + namespace: redhat-quay + channels: [ "stable-3.12" ] + serviceAccountName: quay-sa +---- + +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 link:https://developers.redhat.com/articles/2025/06/02/manage-operators-clusterextensions-olm-v1#3__upgrade_a_clusterextension[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. + +== Using vp-rbac + +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: + +[source,yaml] +---- +vp-rbac: + serviceAccounts: + quay-sa: + namespace: redhat-quay + roleBindings: + clusterRoles: + - cluster-admin +---- + +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: + +[source,yaml] +---- +vp-rbac: + serviceAccounts: + web-terminal-sa: + namespace: web-terminal + roleBindings: + clusterRoles: + - cluster-admin + test-admin: + namespace: aap-config + roleBindings: + clusterRoles: + - cluster-admin + - view-secrets-cms + roles: + - testrole + roles: + testrole: + namespace: aap-config + rules: + - apiGroups: + - '""' + resources: + - configmaps + verbs: + - "list" + - "watch" + clusterRoles: + view-secrets-cms: + rules: + - apiGroups: + - '""' + resources: + - secrets + - configmaps + verbs: + - "get" + - "list" + - "watch" +---- + +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. + +== Using vp-rbac + +You can add vp-rbac to your charts by declaring it as a dependency to your chart, like this (in Chart.yaml): + +[source,yaml] +---- +dependencies: + - name: vp-rbac + version: "0.1.*" + repository: "https://charts.validatedpatterns.io" +---- + +We enhanced our chart-building pipeline to be able to resolve and include chart dependencies for the charts +that we publish in link:https://charts.validatedpatterns.io[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 Want Your Feedback! + +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 link:https://github.com/validatedpatterns/clustergroup-chart/issues[here]. Any issues witht the vp-rbac chart can be reported link:https://github.com/validatedpatterns/vp-rbac-chart/issues[here].