Add latest changes from gitlab-org/gitlab@master

4 files changed, 29 insertions, 11 deletions

diff --git a/doc/ci/jobs/index.md b/doc/ci/jobs/index.md
index 67d1347172a..373cc22e675 100644
--- a/doc/ci/jobs/index.md
+++ b/doc/ci/jobs/index.md
@@ -136,9 +136,9 @@ jobs. Select to expand them.
 To create a group of jobs, in the [CI/CD pipeline configuration file](../yaml/index.md),
 separate each job name with a number and one of the following:
 
-- A slash (`/`), for example, `test 1/3`, `test 2/3`, `test 3/3`.
-- A colon (`:`), for example, `test 1:3`, `test 2:3`, `test 3:3`.
-- A space, for example `test 0 3`, `test 1 3`, `test 2 3`.
+- A slash (`/`), for example, `slash-test 1/3`, `slash-test 2/3`, `slash-test 3/3`.
+- A colon (`:`), for example, `colon-test 1:3`, `colon-test 2:3`, `colon-test 3:3`.
+- A space, for example `space-test 0 3`, `space-test 1 3`, `space-test 2 3`.
 
 You can use these symbols interchangeably.
 
diff --git a/doc/user/admin_area/settings/continuous_integration.md b/doc/user/admin_area/settings/continuous_integration.md
index 7f37c99259a..638b61f6197 100644
--- a/doc/user/admin_area/settings/continuous_integration.md
+++ b/doc/user/admin_area/settings/continuous_integration.md
@@ -91,20 +91,20 @@ The value is in MB and the default is 100MB per job. To change it at the:
 - Instance level:
 
   1. On the top bar, select **Menu > Admin**.
-  1. On the left sidebar, select **Settings > CI/CD**.
-  1. Change the value of maximum artifacts size (in MB).
+  1. On the left sidebar, select **Settings > CI/CD > Continuous Integration and Deployment**.
+  1. Change the value of **Maximum artifacts size (MB)**.
   1. Select **Save changes** for the changes to take effect.
 
 - Group level (this overrides the instance setting):
 
   1. Go to the group's **Settings > CI/CD > General Pipelines**.
-  1. Change the value of **maximum artifacts size (in MB)**.
+  1. Change the value of **Maximum artifacts size** (in MB).
   1. Select **Save changes** for the changes to take effect.
 
 - Project level (this overrides the instance and group settings):
 
   1. Go to the project's **Settings > CI/CD > General Pipelines**.
-  1. Change the value of **maximum artifacts size (in MB)**.
+  1. Change the value of **maximum artifacts size** (in MB).
   1. Select **Save changes** for the changes to take effect.
 
 NOTE:
diff --git a/doc/user/clusters/agent/ci_cd_workflow.md b/doc/user/clusters/agent/ci_cd_workflow.md
index 01ec13c02ef..dce02a72300 100644
--- a/doc/user/clusters/agent/ci_cd_workflow.md
+++ b/doc/user/clusters/agent/ci_cd_workflow.md
@@ -42,7 +42,7 @@ If you have multiple GitLab projects that contain Kubernetes manifests:
 1. [Install the GitLab agent](install/index.md) in its own project, or in one of the
    GitLab projects where you keep Kubernetes manifests.
 1. [Authorize the agent](#authorize-the-agent) to access your GitLab projects.
-1. Optional. For added security, [use impersonation](#use-impersonation-to-restrict-project-and-group-access).
+1. Optional. For added security, [use impersonation](#restrict-project-and-group-access-by-using-impersonation).
 1. [Update your `.gitlab-ci.yml` file](#update-your-gitlab-ciyml-file-to-run-kubectl-commands) to
    select the agent's Kubernetes context and run the Kubernetes API commands.
 1. Run your pipeline to deploy to or update the cluster.
@@ -52,7 +52,7 @@ If you have multiple GitLab projects that contain Kubernetes manifests:
 If you have multiple GitLab projects, you must authorize the agent to access the project where you keep your Kubernetes manifests.
 You can authorize the agent to access individual projects, or authorize a group or subgroup,
 so all projects within have access. For added security, you can also
-[use impersonation](#use-impersonation-to-restrict-project-and-group-access).
+[use impersonation](#restrict-project-and-group-access-by-using-impersonation).
 
 Authorization configuration can take one or two minutes to propagate.
 
@@ -156,7 +156,7 @@ deploy:
   # ... rest of your job configuration
 ```
 
-## Use impersonation to restrict project and group access **(PREMIUM)**
+## Restrict project and group access by using impersonation **(PREMIUM)**
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/345014) in GitLab 14.5.
 
@@ -224,6 +224,24 @@ ci_access:
         ci_job: {}
 ```
 
+#### Example RBAC to restrict CI/CD jobs
+
+The following `RoleBinding` resource restricts all CI/CD jobs to view rights only.
+
+```yaml
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRoleBinding
+metadata:
+  name: ci-job-view
+roleRef:
+  name: view
+  kind: ClusterRole
+  apiGroup: rbac.authorization.k8s.io
+subjects:
+  - name: gitlab:ci_job
+    kind: Group
+```
+
 ### Impersonate a static identity
 
 For a given connection, you can use a static identity for the impersonation.
diff --git a/doc/user/infrastructure/clusters/migrate_to_gitlab_agent.md b/doc/user/infrastructure/clusters/migrate_to_gitlab_agent.md
index aa07a23db18..abdb7c58d82 100644
--- a/doc/user/infrastructure/clusters/migrate_to_gitlab_agent.md
+++ b/doc/user/infrastructure/clusters/migrate_to_gitlab_agent.md
@@ -40,7 +40,7 @@ Some features are currently available only when using certificate-based integrat
 With GitLab-managed clusters, GitLab creates separate service accounts and namespaces
 for every branch and deploys by using these resources.
 
-The GitLab agent uses [impersonation](../../clusters/agent/ci_cd_workflow.md#use-impersonation-to-restrict-project-and-group-access)
+The GitLab agent uses [impersonation](../../clusters/agent/ci_cd_workflow.md#restrict-project-and-group-access-by-using-impersonation)
 strategies to deploy to your cluster with restricted account access. To do so:
 
 1. Choose the impersonation strategy that suits your needs.