Skip to content

Commit 61718ed

Browse files
mhjacksMartin Jackson
mhjacks
and
Martin Jackson
authored
Add olmv1 blog (#592)
* Add olmv1 blog wip * Finish olmv1 blog draft * Correct dates * Avoid unintentional bolding * Add issues links for clustergroup and vp-rbac charts --------- Co-authored-by: Martin Jackson <[email protected]>
1 parent 2e2794c commit 61718ed

File tree

1 file changed

+174
-0
lines changed

1 file changed

+174
-0
lines changed

‎content/blog/2025-08-11-olmv1-support-and-chart-dependencies.adoc‎

Lines changed: 174 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,174 @@
1+
---
2+
date: 2025-08-11
3+
title: Supporting the Latest Standards with Validated Patterns
4+
summary: This post introduces how the Validated Patterns framework supports OLMv1, the new operator packaging standard
5+
author: Martin Jackson
6+
blog_tags:
7+
- patterns
8+
- announce
9+
---
10+
:toc:
11+
:imagesdir: /images
12+
13+
Open Source Technology is always evolving, and we need to be prepared to evolve with it. In OpenShift 4.18, Red Hat
14+
promoted the new OLMv1 packaging standard to General Availability. OLM is the Operator Lifecycle Manager, a vital
15+
component of OpenShift. Users generally do not interact with OLM as such, but they are familiar with how OpenShift
16+
offers Operators to install on clusters and OperatorHub - all of the operators advertized there are offered as OLM
17+
packages.
18+
19+
Up until this point, Validated Patterns have only supported installation via OLMv0. OLMv1 uses the same packaging
20+
format, but places some restrictions on what the bundles can and cannot do. Further, OLMv1 requires a serviceAccount
21+
to explicitly be named to install the bundle. This required changes to one of the framework's key charts, and that in
22+
turn led to changes with how we manage our chart publication pipeline. This blog post will cover three topics:
23+
24+
* Support for OLMv1 objects (ClusterExtensions) in the Validated Patterns Framework
25+
* Using the new vp-rbac chart with Validated Patterns
26+
* How our chart building pipeline had to change
27+
28+
Please note that all of these changes are effective as of the publication of clustergroup chart version 0.9.30, so any
29+
new installation of any publicly maintained Validated Pattern after August 8, 2025 will be able to make use of these
30+
new features.
31+
32+
== Support for OLMv1 (ClusterExtensions)
33+
34+
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
35+
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].
36+
37+
OLMv1 introduces a completely new Kubernetes Kind, the ClusterExtension, which functions somewhat differently than the
38+
Subscription object that previous versions of OLM used. Further, OLMv1 requires the explicit use of a service account
39+
with which to install the operator bundle. OLMv1 is fairly restrictive in not allowing several previously common
40+
methods of declaring version constraints, but over time we expect more operator bundles will support being installed
41+
via OLMv1.
42+
43+
OLMv1 objects are created by passing entries through the Subscriptions object. Each subscription may be an OLMv0 or
44+
OLMv1 object. The determination on which type of object to create is based on the presence of OLMv1 specific fields.
45+
If the object for the subscription contains a "channels", "upgradeConstraintPolicy" or "serviceAccount" key, an OLMv1
46+
ClusterExtension object will be created. Otherwise, the framework will create an OLMv0 Subscription. Existing code
47+
will continue to function as it has.
48+
49+
Here is an example of a subscription object that will create an OLMv1 ClusterExtension:
50+
51+
[source,yaml]
52+
----
53+
---
54+
subscriptions:
55+
quay-operator:
56+
name: quay-operator
57+
namespace: redhat-quay
58+
channels: [ "stable-3.12" ]
59+
serviceAccountName: quay-sa
60+
----
61+
62+
The chart sees the "channels" key and the "serviceAccountName" key and knows that it should create an OLMv1 object
63+
based on that. The name becomes the OLMv1 PackageName. You may also specify a "version" key to pin the subscription
64+
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
65+
"upgradeConstraintPolicy" key.
66+
67+
Additionally, OLMv1 allows multiple channels to be added, so they key "channels" takes an array of channel names.
68+
69+
The final difference is the serviceAccountName. OLMv1 now requires a service account name to install each operator.
70+
Before, the Validated Patterns framework did not have a mechanism to install serviceAccounts, roles, or role
71+
bindings early enough for them to be used to install operators. Several patterns had their own structures for
72+
adding these objects, but they were private to the patterns, or else not especially flexible and could not be
73+
changed without effectively re-writing them. Since that chart had been published under the name "rbac" in our charts
74+
repository, we wrote a new chart that could be used by clustergroup, and could be included as a dependency in other
75+
charts as well.
76+
77+
== Using vp-rbac
78+
79+
The new vp-rbac chart is designed to provision serviceAccounts, roles, clusterRoles, and rolebindings. It was
80+
developed primarily to meet the needs of clustergroup for adding serviceAccounts to install operators with
81+
fine-grained access controls, but can be used for other serviceAccounts scenarios as well.
82+
83+
The (simplest, though perhaps not the most secure) structure needed to install quay looks like this:
84+
85+
[source,yaml]
86+
----
87+
vp-rbac:
88+
serviceAccounts:
89+
quay-sa:
90+
namespace: redhat-quay
91+
roleBindings:
92+
clusterRoles:
93+
- cluster-admin
94+
----
95+
96+
The key ('quay-sa' in this case) becomes the name of the serviceAccount, and the namespace key is required.
97+
Rolebindings can be created for roles or clusterRoles; in this case we bind quay-sa to the (pre-existing)
98+
cluster-admin clusterRole. Rolebindings are always part of the serviceAccount structure for this chart.
99+
100+
The chart also supports creating roles and clusterRoles, if you need to define custom ones. Roles and clusterRoles
101+
support multiple rules. Each rule may specify apiGroups, resources, and verbs. If a rule omits one of these keys,
102+
they each have defaults: apiGroups defaults to [ "'\*'" ] (which includes the empty or core apiGroup); resources
103+
similarly defaults to [ "'*'" ]; verbs defaults to [ 'get', 'list', 'watch' ] (that is, "read-only" permissions).
104+
105+
Here is a more complete example of what can be done with the vp-rbac structure:
106+
107+
[source,yaml]
108+
----
109+
vp-rbac:
110+
serviceAccounts:
111+
web-terminal-sa:
112+
namespace: web-terminal
113+
roleBindings:
114+
clusterRoles:
115+
- cluster-admin
116+
test-admin:
117+
namespace: aap-config
118+
roleBindings:
119+
clusterRoles:
120+
- cluster-admin
121+
- view-secrets-cms
122+
roles:
123+
- testrole
124+
roles:
125+
testrole:
126+
namespace: aap-config
127+
rules:
128+
- apiGroups:
129+
- '""'
130+
resources:
131+
- configmaps
132+
verbs:
133+
- "list"
134+
- "watch"
135+
clusterRoles:
136+
view-secrets-cms:
137+
rules:
138+
- apiGroups:
139+
- '""'
140+
resources:
141+
- secrets
142+
- configmaps
143+
verbs:
144+
- "get"
145+
- "list"
146+
- "watch"
147+
----
148+
149+
This structure allows the creation of structures as fine-grained as you may need, and also makes it straightforward
150+
to create a serviceAccount with admin just to experiment or as a proof-of-concept if you do not know exactly what
151+
permissions are actually needed.
152+
153+
== Using vp-rbac
154+
155+
You can add vp-rbac to your charts by declaring it as a dependency to your chart, like this (in Chart.yaml):
156+
157+
[source,yaml]
158+
----
159+
dependencies:
160+
- name: vp-rbac
161+
version: "0.1.*"
162+
repository: "https://charts.validatedpatterns.io"
163+
----
164+
165+
We enhanced our chart-building pipeline to be able to resolve and include chart dependencies for the charts
166+
that we publish in link:https://charts.validatedpatterns.io[our chart repository].
167+
168+
We may replace some of the RBACs that we create in the patterns framework with the vp-rbac chart, but we
169+
do not plan to do this for all of our charts as this might break backwards compatibility in some cases.
170+
171+
== We Want Your Feedback!
172+
173+
We are excited to offer support for OLMv1 fairly early in its adoption cycle; please feel free to give it a try!
174+
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].

0 commit comments

Comments
 (0)