Balance innovation and agility with security and compliance
risks using a 3-step process across all cloud infrastructure.
Step up business agility without compromising
security or compliance
Everything you need to become a Kubernetes expert.
Always for free!
Everything you need to know about Magalix
culture and much more
According to RedHat’s State of Kubernetes Security Report Spring 2021:
"Not surprisingly, nearly 60% of respondents have experienced a misconfiguration incident in their environment over the last 12 months. Nearly a third have discovered a major vulnerability, and another third said they've suffered a runtime security incident. lastly 20% said they had failed an audit.
We get it. Cloud-native security is hard. Even if we shift security as far left as we can, it doesn’t mean it’s going to translate instantly for someone who has never had the responsibility of security before. Being faced with a security related error message after a commit can seem alarming at first. This is why Magalix provides detailed descriptions of all violations and detailed instructions on how to resolve them. But is that enough?
Before we dive in, let’s agree that all of us are using git. A git repository is our source of truth and any released version can be deployed at any time. These principles are going to the guiding light for some decision you’ll make along the way, such as making a choice to leverage GitOps. For those customers using GitHub, Magalix now supports some advanced features.
When infrastructure and applications are configured declaratively, those that are responsible for managing these systems can use Magalix to incorporate security checks into their existing CI/CD pipelines. Unconfigured security settings, non-compliance, or any other serious misconfiguration discovered at run-time can be costly and could have disastrous outcomes. From 2020 Q3, standards can be enforced at the earliest stages of the software development life cycle using Magalix KubeGuard.
Verbose messaging of test a single Kuberentes manifest against KubeGuard
Since our first release that summer, we have graduated from testing one policy against our KubeGuard policy-on-demand on service, to being able to test all applicable files within a git repository, and then pinpointing exactly where fixes should be implemented within each file.
A GitHub Pull request with suggested fixes in the annotation.
Using our GitHub Action, pull requests are visually modified by adding annotations on the line numbers for what should be fixed. In the image above, we detected on line #28 that “privileged” should be set to ‘false’, and not ‘true’, as it is in the code. Those that are not familiar with this can see exactly where the violation is occurring and what needs to change. This not only educates those who are not familiar with why these types of checks are necessary, it allows those to self-serve, make the changes and continue on.
For some larger organizations, it isn’t so much about education as it is about volume. The sheer number of existing files and repositories that need to be updated with non-root privileges alone could take years! You could use mutating webhooks in Kubernetes but that doesn’t fit with a GitOps approach, where git is the source of truth. If what’s in the repo isn’t what’s running in the environment right now, what’s the point of creating a directory structure that represents your environment’s configuration.
The latest release of our GitHub Action will add simplicity to the process by automatically opening a pull request with the changes set by the Policy enforced.
Automatically opened GitHub Pull Request with the change applied
In the image above, the GitHub Action used the Policies associated with a preconfigured KubeGuard to change the violating values when they are found in a K8s Deployment manifest. You may have also noticed that the formatting got fixed too at line #13. Aside from enforcing the prevention of allowing escalated privileges, other use cases could include mandatory enforcement of using a specific protocol, or standardizing ports.
Identifying violations in your infrastructure as code (and applications) by creating policy-as-code standards is a pathway to shifting security and remediation left. Check code and fix policy violations before merging into the main line branch, and eventually manifesting into Production. Using git as your source-of-truth, having a declarative infrastructure is the perfect candidate to adopt policy-as-code. Enforce standards early on in the development life cycle and prevent costly misconfigurations.
For those using GitHub, Magalix provides additional support by adding inline violation annotations during a pull request when a violation is detected. In addition, our GitHub Action provide Auto-Remediation so pull requests are opened automatically with the fixes already in place.
Let us show you how Magalix and GitHub work together; reach out to one of our experts now.
Empower developers to delivery secure and compliant software with trusted application delivery and policy as code. Learn more.
Automate your deployments with continuous application delivery and GitOps. Read this blog to learn more.