Install OpenShift dependencies and define SCC permissions
This guide explains how to install Mission Control in an OpenShift environment. OpenShift is a cloud-native platform built on Kubernetes that provides automated installation, upgrades, and lifecycle management for containerized applications.
Prerequisites
Before you begin, ensure you have:
-
A working KOTS CLI installation
-
An OpenShift cluster running version 4.8 or later
-
Access to the
occommand-line tool
Install Mission Control and configure service accounts
Follow these steps to install Mission Control in your OpenShift environment:
-
Install the
cert-manageroperator in your OpenShift cluster. For detailed instructions, see the Red Hat OpenShift documentation. -
Configure
cert-managerfor proper secret cleanup. For more information, see Configure cert-manager for proper secret cleanup. -
Install the KOTS CLI if you haven’t already.
-
Install Mission Control by following the instructions in Install Mission Control with KOTS.
-
Configure permissions for Mission Control service accounts using one of the following methods:
-
Use the pre-defined
nonroot-v2SCC -
Create a custom SCC
Run the following commands to grant access to Mission Control service accounts:
oc adm policy add-scc-to-user nonroot-v2 -z loki
oc adm policy add-scc-to-user nonroot-v2 -z mission-control
oc adm policy add-scc-to-user nonroot-v2 -z mission-control-agent
oc adm policy add-scc-to-user nonroot-v2 -z mission-control-aggregator
oc adm policy add-scc-to-user nonroot-v2 -z mission-control-cass-operator
oc adm policy add-scc-to-user nonroot-v2 -z mission-control-dex
oc adm policy add-scc-to-user nonroot-v2 -z mission-control-k8ssandra-operator
oc adm policy add-scc-to-user nonroot-v2 -z mission-control-kube-state-metrics
oc adm policy add-scc-to-user nonroot-v2 -z mission-control-mimirDefine the SCC in a YAML file, and then apply it to your cluster.
|
After creating the SCC or applying policy changes, allow a few minutes for pods to schedule properly. |
For more granular control, create a custom SCC with the necessary permissions for Mission Control service accounts. Use the following example SCC definition:
kind: SecurityContextConstraints
apiVersion: security.openshift.io/v1
metadata:
name: mission-control
runAsUser:
type: MustRunAsNonRoot
seLinuxContext:
type: RunAsAny
fsGroup:
type: RunAsAny
supplementalGroups:
type: RunAsAny
volumes:
- '*'
requiredDropCapabilities:
- ALL
allowedCapabilities:
- NET_BIND_SERVICE
allowHostNetwork: true
allowHostDirVolumePlugin: false
users:
- system:serviceaccount:mission-control:loki
- system:serviceaccount:mission-control:mission-control
- system:serviceaccount:mission-control:mission-control-agent
- system:serviceaccount:mission-control:mission-control-aggregator
- system:serviceaccount:mission-control:mission-control-cass-operator
- system:serviceaccount:mission-control:mission-control-dex
- system:serviceaccount:mission-control:mission-control-k8ssandra-operator
- system:serviceaccount:mission-control:mission-control-kube-state-metrics
- system:serviceaccount:mission-control:mission-control-mimirConfigure cert-manager for proper secret cleanup
Mission Control deletes the certificate objects when you delete a MissionControlCluster, which then deletes all the certificate secrets.
However, the default settings of cert-manager leave the generated secrets behind when the upstream certificates are deleted.
To ensure proper cleanup of certificate secrets when Mission Control clusters are deleted, configure cert-manager to add ownership references on the secrets it generates.
-
Helm installation
-
Kustomize installation
helm install --name cert-manager --namespace cert-manager --version v0.8.1 jetstack/cert-manager --set extraArgs[0]="--enable-certificate-owner-ref=true"Add the following argument to the cert-manager deployment in the cert-manager-controller container:
- '--enable-certificate-owner-ref=true'