To use Airlock Microgateway in your OpenShift cluster, follow this guide to deploy the Airlock Microgateway Operator and its resources.
Prerequisites
- 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 Airlock Microgateway
- Deploy the Airlock Microgateway
CustomResourceDefinitions
: - Deploy the Airlock Microgateway roles:
- Deploy the Airlock Microgateway Operator:
- Verify that the Airlock Microgateway Operator started successfully:
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 allowedCapabilities: - NET_ADMIN
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:
airlock-microgateway-operator-sidecargateway-editor airlock-microgateway-operator-sidecargateway-viewer
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
- After deploying the Airlock Microgateway Operator in your Kubernetes Cluster, the following steps are required:
- Annotate the web application Pods to protect as explained in Annotations for Microgateway Engine injection.
- Create the
CustomResources
to configure the Airlock Microgateway as outlined in Configuration.
Further information and links
- Internal links:
- Annotations for Microgateway Engine injection
- Configuration