Product In-Depth: Magalix KubeGuard

KubeGuard extends Magalix Policies outside of a Kubernetes run-time environment to earlier stages within your existing software development pipelines. KubeGuard is a policy-on-demand service that allows for one or more policies bundled together behind a RESTful endpoint.

In the most practical way, this endpoint can be used in existing CI/CD pipelines and GitOps workflows to catch potential violations before entering Production.  Scan your declarative infrastructure against the same policies that oversee your run-time environments and prevent any violations from entering your mainline branch, let alone your Production environments.

KubeGuard Instantly Shifts your Security Left

KubeGuard works with our containerized (and open source) CI/CD utility to analyze your Kubernetes related YAML files. Take for example, a need for pods to not run as the root user, while ensuring container images are pulled from approved container image registries.

By joining these two policies together under one KubeGuard, you can create internal standards that each manifest has to adhere to. Here’s a crude example of how KubeGuard can be implemented with curl and jq.

 
curl -sX POST \
   --data-binary "@./clean/deployment.yml" \
   -H "Content-Type: application/octet-stream" \
   -o result.json \
   $URL
echo -e "\n===KubeGuard===\n"
jq 'if .violations then .violations  else "No Violations" end' result.json
jq -e '[select(.has_violations == false)] | any' > /dev/null result.json

By POSting a YAML file to my $URL (Kubeguard URL variable), I can save results to a file, and then query the file for the results of my policy scans against that KubeGuard URL. Depending on the outcome, I can send back the proper exit code and allow my CI/CD tool to do the rest.

Be Proactive with KubeGuard!

Today’s DevOps organizations can’t afford unauthorized changes happening outside of existing processes. KubeGuard not only covers your build-time events, but can also be applied at Deploy-Time. What this means is that when a KubeGuard admission controller is enabled, the same KubeGuard that scans your files at Build-Time, can prevent those same files from being applied to your Kubernetes cluster. In a real world sense, if someone with access to your cluster decides they want to run their own stuff, unless it conforms to your standards, you can reject it at the Kubernetes API level.

 
# kubectl apply -f bad-deployment.yml
Error from server ([denied by must-have-owner] Deployment pods must contain labels: {“owner}): error when creating 
 “bad-deployment.yml”: admission web hook “validation.gatekeeper.sh” denied the request: [denied by must-have-owner] 
Deployment pods must contain labels: {“owner”}

An example of a Kubernetes manifest getting denied because it violated an “owner” label policy.

Conclusion

KubeGuard is Magalix Policy on-demand. Combine policies to build Standards for Build-Time and Deploy-Time events with the same Policies that watch over your Run-Time environment. For organizations that have commited to shifting left, KubeGuard simplifies implementing standards by integrating with your existing CI / CD tools, allowing for easy integration and almost zero ramp up time. Be proactive by enabling KubeGuard at both Build and Deploy times so if a rogue action slips through the cracks, you are protected at multiple points of entry.