OpenShift

The Aembit Helm chart supports deploying to OpenShift, including Red Hat OpenShift Service on AWS (ROSA). This page explains the unique considerations when deploying to OpenShift.

ServiceAccount and SecurityContextConstraint resources

OpenShift provides an additional layer of security policy in terms of SecurityContextConstraint (SCC). Each SCC limits the options available to Pod resources, including those embedded in Deployment resources. Your cluster rejects any pod that uses a disallowed option within its securityContext field.

SCC for Agent Controller and Agent Injector

When you deploy the Aembit Helm chart, specify an SCC that you expect the Agent Controller and Agent Injector to run under by setting:

--set serviceAccount.openshift.scc=anyuid

Choose anyuid unless you need to use a custom SCC. If you use a custom SCC, grant it these permissions:

allowPrivilegeEscalation: false
allowedCapabilities:
    - NET_BIND_SERVICE
runAsUser:
    type: RunAsAny

The Aembit Helm chart uses the permissions of the user or the service account deploying the chart to create a new ServiceAccount resource named aembit. It then gives the aembit service account permission to use the named SCC. Each service account is only able to grant permissions it has for itself. To avoid permission errors at this step, ensure the helm chart deployer has permission to use the named SCC or else this fails. For a test deployment, deploy as a user with the cluster-admin role. When deploying the helm chart using a service account, run the following command to see if the service account appears in the list:

oc adm policy who-can use SecurityContextConstraints <anyuid or custom SCC name>

Deploying the Aembit Helm chart from ArgoCD presents an additional challenge by concealing the service account that ArgoCD uses to configure your cluster. Contact your ArgoCD administrator to ask them to confirm that ArgoCD’s service account is in the output of the who-can command.

SCC for Client Workloads and Agent Proxy

OpenShift admits your pod under the most restrictive SCC that’s both compatible with the securityContext field specified in your pod and compatible with the container image specified in your pod. OpenShift considers each of the SCCs available to the deployer of the pod.

The Agent Proxy is capable of running under the restricted-v2. To accomplish this, first set:

--set agentProxy.runAsRestricted=true

With this set, the Agent Proxy container definition uses a securityContext that is compatible with the restricted-v2 SCC. However, the container image declares an empty User value. This retains compatibility with the many supported deployment options for the container image. OpenShift considers this an intention to run as the root user, triggering OpenShift to admit the Client Workload pod under any of the deployer’s SCCs that allows running as the root user. To ensure your Client Workload pod runs under the restricted-v2 SCC whenever possible, deploy it using a service account that only has permission to use the restricted-v2 SCC.

Explicit versus transparent steering

When you deploy Pods to your cluster, annotate them to opt into explicit steering. Configure your Client Workloads to use the Agent Proxy as an HTTP or HTTPS proxy.

metadata:
  annotations:
    aembit.io/agent-inject: "enabled"
    aembit.io/steering-mode: "explicit"

To provide transparent steering, the Agent Init container needs to install iptables rules. OpenShift clusters don’t expose these features to pods. When you configure your Client Workload pod for explicit steering, the Agent Injector omits the Agent Init container. If you configure your Client Workload pod for transparent steering, expect to see these errors in the aembit-init-iptable container logs:

owner: Could not determine whether revision 1 is supported, assuming it is.
CT: Could not determine whether revision 2 is supported, assuming it is.
iptables v1.8.9 (legacy): can't initialize iptables table `raw': Permission denied (you must be root)
Perhaps iptables or your kernel needs to be upgraded.