Assess the active configuration

There are a number of reasons why it could be interesting to assess the active Microgateway configurations.

  • Reasons for assessing the configuration:
  • Current attack vector (e.g. Log4Shell).
  • Mistake in older template or guideline.
  • Feedback from operations to adjust a setting.
  • Before preventing a certain setting with a new policy.
  • Get an overview of used features before upgrading.
  • After upgrading to enable certain settings.
  • ...

No matter the motivation, the aim is to find all configurations with a certain setting enabled, disabled, or not used at all. By identifying the affected configurations, further actions can be initiated.

Critical security settings should be enforced with policies. It is not recommended to assess active configuration to check policy compliance solely.

Tooling

The Microgateway configuration is defined as Kubernetes resources that could be assessed in different ways. The most obvious ones are mentioned as follows.

  • How to assess active configuration:
  • With the power of kubectl.
  • With the power of kubectl combined with jq.
  • Configure policies in audit mode.

    • Policy tools can usually create policies in audit mode. Violating configurations will not be prevented from being deployed but it is possible to get a report of those configurations. Additionally, policies can also be enabled for background scanning, so old Kubernetes resources would be evaluated too. To follow this approach, consider Enforce policies but set the mode to audit. For further information read the manual of the corresponding tool.

  • Investigate the Kubernetes resources directly in Git.

    • If a GitOps process is in place, that would be an additional possibility.

General tips for working with CRs

  • CLI:
  • Use kubectl explain <replace with CRD name> --recursive to list all available options and the YAML structure.
  • Check the CRD description texts with kubectl explain <replace with CRD name and path> of the available options for more details.
  • API Reference documentation:
  • Click on the link to open the CR-related documentation in a new browser tab or window: CRD Reference documentation. See also the API Reference documentation links at the end article.

Examples

The examples show how to assess the Kubernetes resources using kubectl. This way it is possible to get an overview of deployed resources and their settings. Withjq even more sophisticated queries are possible.

copy
# List status of SidecarGateways
kubectl get sidecargateways.microgateway.airlock.com -o=custom-columns='NAME:{.metadata.name},STATUS:{.status.status}' --sort-by=.metadata.name
copy
# List used native Envoy HTTP filters
kubectl get envoyhttpfilters.microgateway.airlock.com -o=custom-columns='NAME:{.metadata.name},ENVOY_FILTER:{.spec.value.typed_config.\@type}' --sort-by=.metadata.name
copy
# List DenyRules and the configured level and threatHandlingMode.
kubectl get denyrules.microgateway.airlock.com -o=custom-columns='NAME:{.metadata.name},LEVEL:{.spec.request.builtIn.settings.level},THREAT_HANDLING_MODE:{.spec.request.builtIn.settings.threatHandlingMode}' --sort-by=.metadata.name
copy
# List the DenyRules with level "Standard"
kubectl get denyrules.microgateway.airlock.com -o=json | jq '.items[] | select(.spec.request.builtIn.settings.level == "Standard") | [ .metadata.name, .spec.request.builtIn.settings.level ] | @csv'

The different log types, such as access or application logs, can be printed using the kubectl logs as mixed output. You may filter the printed logs according to your needs for better orientation.

  • Use kubectl logs <POD> -c airlock-microgateway-engine to print the logs for the engine container in a pod. For more options, see kubectl logs reference.
  • Use grep <query> to filter the log-message output according to your requirements.
  • With the jq-JSON processor (or equivalent) installed, you may pipe the logs output to the processor for better formatting and readability. See JQ for further information.