OpenShift

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.

copy
# Deploy the cert-manager
kubectl apply -k "https://github.com/airlock/microgateway/examples/utilities/cert-manager/?ref=4.2.1"

# Wait for the cert-manager to be up and running
kubectl -n cert-manager wait --for=condition=ready --timeout=600s pod -l app.kubernetes.io/instance=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 of kube-system.
  • All pods that Airlock Microgateway should protect must explicitly reference the Airlock Microgateway CNI NetworkAttachmentDefinition via the annotation k8s.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.

  1. 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.
  2. copy
    helm install airlock-microgateway-cni -n openshift-operators oci://quay.io/airlockcharts/microgateway-cni --version 4.2.1 -f https://github.com/airlock/microgateway/tree/4.2.1/deploy/charts/airlock-microgateway-cni/openshift-values.yaml --version 4.2.1
  3. Wait for the Airlock Microgateway Operator to be up and running.
  4. copy
    oc -n airlock-microgateway-system wait --for=condition=Available deployments --all --timeout=3m 
  5. Verify the correctness of the installation with helm test.
  6. copy
    helm upgrade airlock-microgateway-cni -n openshift-operators oci://quay.io/airlockcharts/microgateway-cni --set tests.enabled=true --reuse-values --version 4.2.1
  7. Check the log messages.
  8. copy
    helm test airlock-microgateway-cni -n openshift-operators --logs
  9. On successful installation, the logs should show the message Success.
  10. Disable the helm test deployment afterward.
  11. copy
    helm upgrade airlock-microgateway-cni -n openshift-operators  oci://quay.io/airlockcharts/microgateway-cni --set tests.enabled=false --reuse-values --version 4.2.1

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.

  1. Deploy the CRDs.
  2. copy
    kubectl apply -k "https://github.com/airlock/microgateway/deploy/crds/?ref=4.2.1"

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.

  1. Create the airlock-microgateway-system namespace
  2. copy
    oc create namespace airlock-microgateway-system
  3. Store the license in the Microgateway Operator namespace, in a Kubernetes secret with the name airlock-microgateway-license and the key microgateway-license.txt. Use the following command:
  4. copy
    oc -n airlock-microgateway-system create secret generic airlock-microgateway-license  
    --from-file=microgateway-license.txt=<my-local-microgateway-license.txt>
  5. Adapt and run the following command with the current Airlock Microgateway Operator Helm chart version. This will install airlock-microgateway in the airlock-microgateway-system namespace.
  6. copy
    helm install -n airlock-microgateway-system airlock-microgateway oci://quay.io/airlockcharts/microgateway --wait --version 4.2.1
  7. Verify that the Airlock Microgateway Operator started successfully:
  8. copy
    oc -n airlock-microgateway-system wait --for=condition=Available deployments --all --timeout=3m
  9. Verify the correctness of the installation with helm test.
  10. copy
    helm upgrade airlock-microgateway -n airlock-microgateway-system oci://quay.io/airlockcharts/microgateway --set tests.enabled=true --reuse-values --version 4.2.1
  11. Check the log messages.
  12. copy
    helm test airlock-microgateway -n airlock-microgateway-system --logs

    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).

  13. On successful installation, the logs should show the following message: ### Installation of 'airlock-microgateway' succeeded
  14. Disable the helm test deployment afterward.
  15. copy
    helm upgrade airlock-microgateway -n airlock-microgateway-system oci://quay.io/airlockcharts/microgateway --set tests.enabled=false --reuse-values --version 4.2.1

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:

copy
kubectl apply -k "https://github.com/airlock/microgateway/deploy/crd-rbac/?ref=4.2.1"

What's next

  1. After deploying the Airlock Microgateway Operator in your Cluster, the following steps are required:
  2. Configure/change the Airlock Microgateway license. See article Licensing and license-dependent behavior.
  3. Annotate the web application Pods to protect as explained in Labels and annotations for Airlock Microgateway.
  4. Create the CustomResources to configure the Airlock Microgateway as outlined in Configuration.
  5. Append default/airlock-microgateway-cni in the annotation k8s.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.