Microgateway Operator

The Microgateway Operator container injects the Microgateway Engine Container into web application Pods annotated with sidecar.microgateway.airlock.com/inject: "true". The Operator configures the Engine based on Custom Resources that contain the Engine configuration.

In addition, the Microgateway Operator monitors these pods and reconfigures them whenever a Custom Resource changes.

Configuration overview

  • The Microgateway Operator is configured by different files:
  • The main configuration file operator_config.yaml.
  • Files that are referenced in the operator_config.yaml file:
    • deployment.sidecar.engineContainerTemplate
    • deployment.sidecar.networkManagerContainerTemplate
    • engine.bootstrapConfigTemplate

These files are stored in the Config Map airlock-microgateway-operator-operator-config in the Microgateway Operator namespace. The Config Map is configured in the Microgateway Operator deployment to be mounted at the correct location.

The configuration files in the Config Map airlock-microgateway-operator-operator-config are only read at startup.

  • The Microgateway Operator must be restarted once the file operator_config.yaml or the referenced template files has been changed.
  • The protected Pods must be restarted when the referenced template files have been changed.

Example configuration

The following snippet shows an excerpt of the main Microgateway Operator configuration file operator_config.yaml with its default settings:

copy
// Default Operator configuration 
apiVersion: config.airlock.com/v1alpha1 
kind: OperatorConfig 
log:
  level: info  
health: 
  healthProbeBindAddress: :8081 
metrics: 
  bindAddress: 127.0.0.1:8080 
webhook: 
  port: 9443
  
// Extensions: Airlock Microgateway Operator
deployment: 
  sidecar: 
    engineContainerTemplate: "/sidecar/engine_container_template.yaml" 
    networkManagerContainerTemplate: "/sidecar/network_manager_container_template.yaml" 
engine: 
  bootstrapConfigTemplate: "/engine_bootstrap_config_template.yaml"

Configuration options of the Envoy discovery services and their corresponding APIs are called xDS​. See xDS general information. Discovery services are used, i.e., to configure the Microgateway Engine dynamically.

The following parameters can also be adapted if required:

Parameter

Default value

Description

health.healthProbeBindAddress

:8081

Address the controller should bind to serve health probes.

metrics.bindAddress

127.0.0.1:8080

Address the controller should bind to serve Prometheus metrics. It can be set to 0 to disable the metrics serving.

webhook.port

:9443

The port the webhook server serves at.

See also the API Reference documentation link at the end of this article.

TLS certificate generation and renewal

Any communication between containers in the airlock-microgateway-system namespace and with web application pods (with injected Airlock Microgateway Engines) is secured using TLS.

  • Certificate generation and renewal
  • During the Microgateway Operator startup, the following self-signed certificates are generated and stored as secrets in the airlock-microgateway-system namespace:
    • airlock-microgateway-ca-cert – the CA certificate to generate self-signed TLS certificates.
    • webhook-server-cert – the server certificate of the Microgateway Operator.
    • airlock-microgateway-license-guard-cert – the certificate of the Microgateway License Guard.
    • airlock-microgateway-license-guard-redis-cert – the certificate of the Microgateway License Guard Redis DB.
  • Each time an Airlock Microgateway Engine sidecar is injected, an airlock-microgateway-bootstrap-secret is generated and saved to the web application namespace. This secret holds the required certificates and keys for TLS-based communication. The TLS certificates of the bootstrap secret are renewed automatically every 48h.