To use Airlock Microgateway in your OpenShift cluster, follow this guide to deploy the Airlock Microgateway Operator and its resources.


  • Deploy the cert-manager in your Kubernetes cluster.

For an easy start in non-production environments, you may deploy the same cert-manager we are use for internal testing. Note that the files provided are not intended for production use! Consult the manual for productive environments (Kubernetes) Install cert-manager.

# Deploy the cert-manager
kubectl apply -k

# Wait for the cert-manager to be up and running
kubectl -n cert-manager wait --for=condition=ready --timeout=600s pod -l

Deploy Airlock Microgateway

  1. Deploy the Airlock Microgateway CustomResourceDefinitions:
  2. copy
    oc apply -k
  3. Deploy the Airlock Microgateway roles:
  4. copy
    oc apply -k
  5. Deploy the Airlock Microgateway Operator:
  6. copy
    oc apply -k
  7. Verify that the Airlock Microgateway Operator started successfully:
  8. copy
    oc -n airlock-microgateway-system wait --for=condition=Available deployments --all --timeout=3m    

As mentioned in Requirements and Limitations, the serviceAccount used for the web application Pod requires the capability NET_ADMIN and must run in privileged mode. Ensure that this is not restricted by PodSecurityPolicy, Open Policy Agent Gatekeeper, Kyverno, or any other solution to enforce policies.

Security Context Constraint (SCC) for the web application Pod

The Airlock Microgateway Operator injects the Microgateway Network Manager as the init container in the protected web application Pod. The Microgateway Network Manager sets up the Pod network traffic redirection to/from the Microgateway Engine container. By default, OpenShift prohibits the privileges which the Microgateway Network Manager requires.

The Microgateway Network Manager needs the following privileges which must be assigned to the serviceAccount of the protected web application Pod:

readOnlyRootFilesystem: false
allowPrivilegeEscalation: true
allowPrivilegedContainer: true

The default SCC privileged provides sufficient rights and could be used for the serviceAccount. For further information consult the OpenShift website (Default security context constraints).

To use the default SCC for the serviceAccount, follow the instructions below. Replace <target-serviceaccount> with the appropriate serviceAccount.

  • To grant the required permissions to a serviceAccount, you can do the following:
  • oc adm policy add-scc-to-group privileged system:serviceaccounts:<target-serviceaccount>
  • When removing your web application, the permissions can be removed as follow:
  • oc adm policy remove-scc-from-group privileged system:serviceaccounts:<target-serviceaccount>

ClusterRoles to interact with Airlock Microgateway CustomResources

The Kubernetes manifest file contains two ClusterRoles for each CRD. One with viewer and one with editor rights.
They follow the naming schema as described below:

airlock-microgateway-operator-<CRD name>-editor 
airlock-microgateway-operator-<CRD name>-viewer

As example for the CRD SidecarGateway:


Users who must be able to create and view Airlock Microgateway CRs need the required -editor ClusterRoles assigned to their user. Users who only need to view (read-only rights) Airlock Microgateway CRs need the required -viewer ClusterRoles assigned to their user.

Because each CRD comes with its own ClusterRoles, Administrators can grant access fine granular.

What's next

  1. After deploying the Airlock Microgateway Operator in your Kubernetes Cluster, the following steps are required:
  2. Annotate the web application Pods to protect as explained in Annotations for Microgateway Engine injection.
  3. Create the CustomResources to configure the Airlock Microgateway as outlined in Configuration.