docs(agent): added non-root & openshift installation instructions

src/pages/docs/infrastructure/workers/kubernetes-worker/index.md

@@ -59,6 +59,10 @@ create new pods for each requested operation.
 
 The Kubernetes Worker allows execution permissions to be overwritten in the same way as the [Kubernetes Agent](/docs/kubernetes/targets/kubernetes-agent/permissions).
 
+## Non-root mode
+
+The Kubernetes Worker non-root mode can be configured in the same way as the [Kubernetes Agent](/docs/kubernetes/targets/kubernetes-agent#non-root-mode).
+
 ## Limitations
 
 Being securely hosted inside a kubernetes cluster comes with some limitations - the primary of which is the lack of `Docker`.

src/pages/docs/kubernetes/targets/kubernetes-agent/index.md

@@ -167,6 +167,67 @@ Look at the Helm chart [values.yaml](https://github.com/OctopusDeploy/helm-chart
 
 The Kubernetes monitor is deployed as a sub-chart to the Kubernetes agent. [Available values for the monitor are available here](https://github.com/OctopusDeploy/helm-charts/blob/main/charts/kubernetes-agent/kubernetes-monitor.md). All Kubernetes monitor values should be nested under a `kubernetesMonitor` key when deployed with the Kubernetes agent chart.
 
+### Non-root configuration
+
+Agent and script pods support running in non-root mode. UID/GID should be 999.
+
+```yaml
+agent:
+  securityContext:
+    runAsUser: 999
+    runAsGroup: 999
+    fsGroup: 999
+    fsGroupChangePolicy: "OnRootMismatch"
+scriptPods:
+  securityContext: 
+    runAsUser: 999
+    runAsGroup: 999
+    fsGroup: 999
+    fsGroupChangePolicy: "OnRootMismatch"
+persistence:
+  storageClassName: {your-custom-value} #required
+```
+
+To make sure that you will not have problems with PV StorageClass requires to have explicit UID to match one from securityContext. Here is important part of your StorageClass `mountOptions`:
+
+```yaml
+mountOptions:
+- uid=999
+- forceuid
+- file_mode=0775 #rwx for user required
+- dir_mode=0775 #rwx for user required
+```
+
+### Openshift
+
+Agent can be run under `nonroot-v2` SCC. This means you will probably need to manually assign the SCC to service accounts:
+
+- **Agent**
+
+```bash
+NS_NAME="octopus-agent-<name>"
+AGENT_SERVICE_ACCOUNT="octopus-agent-tentacle"
+oc adm policy add-scc-to-user nonroot-v2 -z $AGENT_SERVICE_ACCOUNT -n $NS_NAME
+```
+
+- **Pod scripts**
+
+```bash
+NS_NAME="octopus-agent-<name>"
+POD_SCRIPTS_SERVICE_ACCOUNT="octopus-agent-scripts"
+oc adm policy add-scc-to-user nonroot-v2 -z $POD_SCRIPTS_SERVICE_ACCOUNT -n $NS_NAME
+```
+
+- **Auto-upgrader**
+
+```bash
+NS_NAME="octopus-agent-<name>"
+POD_SCRIPTS_SERVICE_ACCOUNT="octopus-agent-auto-upgrader"
+oc adm policy add-scc-to-user nonroot-v2 -z $POD_SCRIPTS_SERVICE_ACCOUNT -n $NS_NAME
+```
+
+For additional details on the helm values for non-root setup, see the [Non-root configurationg](#non-root-configuration) section.
+
 ## Configuring the agent with Tenants
 
 While the wizard doesn't support selecting Tenants or Tenant tags, the agent can be configured for tenanted deployments in two ways: