To use Airlock Microgateway in your OpenShift cluster, follow this guide to deploy the Airlock Microgateway Operator and its resources.
Prerequisites
- To use Airlock Microgateway, a valid license is required. Airlock Microgateway is available in a Premium and a free Community edition. To request and configure/change a license, see the article Licensing and license-dependent behavior.
- Deploy the
cert-manager
in your Kubernetes cluster.
For an easy start in non-production environments, you may deploy the same cert-manager
we 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.
Preset chart
For the CNI DaemonSet installation, an openshift-values.yaml
preset chart is available. Check the folder /microgateway/deploy/charts/airlock-microgateway-cni
on GitHub for the latest chart file.
- Use the
openshift-values.yaml
file when installing the CNI plugin. The chart can be applied using-f <chart-name>
directly from GitHub or a local source. - We recommend installing the CNI plugin into the namespace
openshift-operators
instead ofkube-system
. - All pods that Airlock Microgateway should protect must explicitly reference the Airlock Microgateway CNI
NetworkAttachmentDefinition
via the annotationk8s.v1.cni.cncf.io/networks
.
The chart has been tested in our environment. Depending on your setup, the required presets could vary.
Microgateway CNI installation
Install the CNI DaemonSet and required openshift-values.yaml
preset chart with helm.
Privileged access is required to install the Microgateway CNI plugin on the node. In OpenShift, this may lead to a warning if the label pod-security.kubernetes.io/warn: privileged
is not set for the OpenShift operator namespace during the CNI helm install process. For the related OpenShift documentation, see Managing pod security admission in OpenShift.
- Adapt and run the following command with the current CNI helm chart version from GitHub or a local version of the
openshift-values.yaml
file. - Wait for the Airlock Microgateway Operator to be up and running.
- Verify the correctness of the installation with
helm test
. - Check the log messages.
- On successful installation, the logs should show the message
Success
. - Disable the
helm test
deployment afterward.
Airlock Microgateway CRDs deployment
CRDs are cluster-wide resources and thus have to be deployed separately from the Helm chart-driven Airlock Microgateway Operator deployment.
- Deploy the CRDs.
Install the Airlock Microgateway Operator
In order to complete the Airlock Microgateway Operator installation and to run the below help test
successfully, you need to deploy a valid license. See article Licensing and license-dependent behavior for more information.
- Create the
airlock-microgateway-system
namespace - Store the license in the Microgateway Operator namespace, in a Kubernetes secret with the name
airlock-microgateway-license
and the keymicrogateway-license.txt
. Use the following command: - Adapt and run the following command with the current Airlock Microgateway Operator Helm chart version. This will install
airlock-microgateway
in theairlock-microgateway-system
namespace. - Verify that the Airlock Microgateway Operator started successfully:
- Verify the correctness of the installation with
helm test
. - Check the log messages.
- On successful installation, the logs should show the following message:
### Installation of 'airlock-microgateway' succeeded
- Disable the
helm test
deployment afterward.
During installation, the installation status is echoed – i.e., the preliminary cleanup task and scaling the test installation to only 1 replica (to ensure no pods from previous runs are present).
Security Context Constraint (SCC)
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).
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 has its ClusterRoles, administrators can define fine-grained access control.
Note: The RBAC rules are not installed by default. To do so execute the following command:
What's next
- After deploying the Airlock Microgateway Operator in your Cluster, the following steps are required:
- Configure/change the Airlock Microgateway license. See article Licensing and license-dependent behavior.
- Annotate the web application Pods to protect as explained in Labels and annotations for Airlock Microgateway.
- Create the
CustomResources
to configure the Airlock Microgateway as outlined in Configuration. - Append
default/airlock-microgateway-cni
in the annotationk8s.v1.cni.cncf.io/networks
of the web application Pod to allow the Microgateway CNI plugin work together with OpenShift Multus. For example:k8s.v1.cni.cncf.io/networks: [<network>,...],default/airlock-microgateway-cni
. For further information consider Adding a pod to an additional network in OpenShift.