Skip to content

Commit 0100ce2

Browse files
authored
Merge pull request #32088 from sounix000/Usage_of_privileged_build_RHDEVDOCS_2384
RHDEVDOCS-2384: Document usage of privileged builds and the new default SCC `pipelines-scc` for SA `pipelines`.
2 parents 5271673 + ffacced commit 0100ce2

File tree

5 files changed

+120
-7
lines changed

5 files changed

+120
-7
lines changed

_topic_map.yml

Lines changed: 4 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1385,10 +1385,12 @@ Topics:
13851385
File: uninstalling-pipelines
13861386
- Name: Creating CI/CD solutions for applications using OpenShift Pipelines
13871387
File: creating-applications-with-cicd-pipelines
1388-
- Name: Reducing resource consumption of OpenShift Pipelines
1389-
File: reducing-pipelines-resource-consumption
13901388
- Name: Working with OpenShift Pipelines using the Developer perspective
13911389
File: working-with-pipelines-using-the-developer-perspective
1390+
- Name: Reducing resource consumption of OpenShift Pipelines
1391+
File: reducing-pipelines-resource-consumption
1392+
- Name: Using pods in a privileged security context
1393+
File: using-pods-in-a-privileged-security-context
13921394
- Name: GitOps
13931395
Dir: gitops
13941396
Distros: openshift-enterprise
Lines changed: 30 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,30 @@
1+
[id='using-pods-in-a-privileged-security-context']
2+
= Using pods in a privileged security context
3+
include::modules/common-attributes.adoc[]
4+
include::modules/pipelines-document-attributes.adoc[]
5+
:context: using-pods-in-a-privileged-security-context
6+
7+
toc::[]
8+
9+
The default configuration of OpenShift Pipelines 1.3.x and later versions does not allow you to run pods with privileged security context, if the pods result from pipeline run or task run.
10+
For such pods, the default service account is `pipeline`, and the security context constraint (SCC) associated with the `pipelines` service account is `pipelines-scc`. The `pipelines-scc` SCC is similar to the `anyuid` SCC, but with a minor difference as defined in the YAML file for the SCC of pipelines:
11+
12+
.Example `SecurityContextConstraints` object
13+
[source,yaml,subs="attributes+"]
14+
----
15+
apiVersion: security.openshift.io/v1
16+
kind: SecurityContextConstraints
17+
...
18+
fsGroup:
19+
type: MustRunAs
20+
...
21+
----
22+
23+
In addition, the `Buildah` cluster task, shipped as part of the OpenShift Pipelines, uses `vfs` as the default storage driver.
24+
25+
include::modules/op-running-pipeline-and-task-run-pods-with-privileged-security-context.adoc[leveloffset=+1]
26+
27+
28+
== Additional resources
29+
30+
* For information on managing SCCs, refer to xref:../../authentication/managing-security-context-constraints.adoc[Managing security context constraints].

modules/op-release-notes-1-4.adoc

Lines changed: 15 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -89,7 +89,7 @@ Support for `when` expressions and `finally` tasks are unavailable in the {produ
8989

9090
* The `pipelines-scc` Security Context Constraint (SCC) is used with the default `pipeline` service account for pipelines. This new service account is similar to `anyuid`, but with a minor difference as defined in the YAML for SCC of {product-title} 4.7:
9191
+
92-
[source, YAML]
92+
[source,yaml,subs="attributes+"]
9393
----
9494
fsGroup:
9595
type: MustRunAs
@@ -106,7 +106,12 @@ fsGroup:
106106

107107
* The `creds-init` helper image for building and deploying is removed.
108108

109-
* In the triggers spec and binding, the deprecated field `template.Name` is removed in favor of `template.Ref`.
109+
* In the triggers spec and binding, the deprecated field `template.name` is removed in favor of `template.ref`. You should update all `eventListener` definitions to use the `ref` field.
110+
+
111+
[NOTE]
112+
====
113+
Upgrade from {pipelines-shortname} 1.3.x and earlier versions to {pipelines-shortname} 1.4.0 breaks event listeners because of the unavailability of the `template.name` field. For such cases, use {pipelines-shortname} 1.4.1 to avail the restored `template.name` field.
114+
====
110115

111116
* For `EventListener` custom resources/objects, the fields `PodTemplate` and `ServiceType` are deprecated in favor of `Resource`.
112117

@@ -128,7 +133,7 @@ fsGroup:
128133

129134
* Triggers throw error resulting from bad handling of the JSON format, if you have the following configuration in the trigger binding:
130135
+
131-
[source, YAML]
136+
[source,yaml,subs="attributes+"]
132137
----
133138
params:
134139
- name: github_json
@@ -138,12 +143,14 @@ To resolve the issue:
138143
** If you are using triggers v0.11.0 and above, use the `marshalJSON` CEL function, which takes a JSON object or array and returns the JSON encoding of that object or array as a string.
139144
** If you are using older triggers version, add the following annotation in the trigger template:
140145
+
141-
[source, YAML]
146+
[source,yaml,subs="attributes+"]
142147
----
143148
annotations:
144149
triggers.tekton.dev/old-escape-quotes: "true"
145150
----
146151

152+
* When upgrading from {pipelines-shortname} 1.3.x to 1.4.x, you must recreate the routes.
153+
147154
[id="fixed-issues-1-4_{context}"]
148155
== Fixed issues
149156

@@ -186,3 +193,7 @@ annotations:
186193
* Previously, a pipeline result that contained an invalid variable would be added to the pipeline run with the literal expression of the variable intact. Therefore, it was difficult to assess whether the results were populated correctly. This issue is fixed by filtering out the pipeline run results that reference failed task runs. Now, a pipeline result that contains an invalid variable will not be emitted by the pipeline run at all.
187194

188195
* The `tkn eventlistener describe` command is fixed to avoid crashing without a template. It also displays the details about trigger references.
196+
197+
* Upgrades from {pipelines-shortname} 1.3.x and earlier versions to {pipelines-shortname} 1.4.0 breaks event listeners because of the unavailability of `template.name`. In {pipelines-shortname} 1.4.1, the `template.name` has been restored to avoid breaking event listeners in triggers.
198+
199+
* In {pipelines-shortname} 1.4.1, the `ConsoleQuickStart` custom resource has been updated to align with {product-title} 4.7 capabilities and behavior.
Lines changed: 69 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,69 @@
1+
[id='op-running-pipeline-and-task-run-pods-with-privileged-security-context']
2+
= Running pipeline run and task run pods with privileged security context
3+
:context: op-running-pipeline-and-task-run-pods-with-privileged-security-context
4+
5+
toc::[]
6+
7+
.Procedure
8+
9+
To run a pod (resulting from pipeline run or task run) with the `privileged` security context, do the following modifications:
10+
11+
* Configure the associated user account or service account to have an explicit SCC. You can perform the configuration using any of the following methods:
12+
** Execute the following OpenShift command:
13+
+
14+
[source, terminal]
15+
----
16+
$ oc adm policy add-scc-to-user <scc-name> -z <service-account-name>
17+
----
18+
** Alternatively, modify the YAML files for `RoleBinding`, and `Role` or `ClusterRole`:
19+
20+
+
21+
.Example `RoleBinding` object
22+
[source,yaml,subs="attributes+"]
23+
----
24+
apiVersion: rbac.authorization.k8s.io/v1
25+
kind: RoleBinding
26+
metadata:
27+
name: service-account-name <1>
28+
namespace: default
29+
roleRef:
30+
apiGroup: rbac.authorization.k8s.io
31+
kind: ClusterRole
32+
name: pipelines-scc-clusterrole <2>
33+
subjects:
34+
- kind: ServiceAccount
35+
name: pipeline
36+
namespace: default
37+
38+
----
39+
<1> Substitute with an appropriate service account name.
40+
<2> Substitute with an appropriate cluster role based on the role binding you use.
41+
42+
+
43+
.Example `ClusterRole` object
44+
[source,yaml,subs="attributes+"]
45+
----
46+
apiVersion: rbac.authorization.k8s.io/v1
47+
kind: ClusterRole
48+
metadata:
49+
name: pipelines-scc-clusterrole <1>
50+
rules:
51+
- apiGroups:
52+
- security.openshift.io
53+
resourceNames:
54+
- nonroot
55+
resources:
56+
- securitycontextconstraints
57+
verbs:
58+
- use
59+
----
60+
<1> Substitute with an appropriate cluster role based on the role binding you use.
61+
62+
+
63+
[NOTE]
64+
====
65+
As a best practice, create a copy of the default YAML files and make changes in the duplicate file.
66+
====
67+
+
68+
69+
* If you do not use the `vfs` storage driver, configure the service account associated with the task run or the pipeline run to have a privileged SCC, and set the security context as `privileged: true`.

modules/security-context-constraints-about.adoc

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -31,7 +31,7 @@ If you have `cluster-admin` privileges, you can adjust the default SCC policies
3131
be more permissive.
3232
////
3333

34-
The cluster contains eight default SCCs:
34+
The cluster contains nine default SCCs:
3535

3636
* `anyuid`
3737
* `hostaccess`
@@ -48,6 +48,7 @@ effectively root on the cluster and must be trusted accordingly.
4848
* `nonroot`
4949
* `privileged`
5050
* `restricted`
51+
* `pipelines-scc`
5152

5253

5354
[IMPORTANT]

0 commit comments

Comments
 (0)