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 withjq
. - Configure policies in audit mode.
- Notice
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.
- Notice
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.
# List status of SidecarGateways kubectl get sidecargateways.microgateway.airlock.com -o=custom-columns='NAME:{.metadata.name},STATUS:{.status.status}' --sort-by=.metadata.name
# 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
# 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
# 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.
Further information and links
External links: