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
The benefits of cloud-native application development are endless, but there can be significant risks. Modern development practices and technologies, like CI/CD, containers, microservices, and self-provisioning, require greater visibility and control to account for the faster and more dynamic software delivery cycle.
The 24/7 nature of modern software systems which are expected to be highly-available, seamlessly responsive, and infinitely scalable, presents unique challenges to traditional development and operations teams.
Operation and security teams can’t possibly administer all cloud instances and workloads manually to ensure adherence to operational best practices, security rules, and organizational standards. Manual administration will slow your innovation cadence, and it won’t scale.
This can be a lot to consider, but if you rethink your organization culture and adopt the DevSecOps culture, you will also want to adopt a Policy-as-Code strategy to maintain your pace of innovation.
Codifying and automating your operational best practices, security rules, and organizational standards is a must to ensure a healthy balance between an organization’s rate of innovation and its risk posture.
Similar to the concept of Infrastructure-as-Code (IaC) and the benefits you get from codifying your infrastructure setup, Policy-as-Code (PaC) is the codification of your policies. You can think of your policies as the linting rules for your IaC.
Overall, this refers to the ability of your operation team to verify and enforce certain rules and standards across the entire organization or within specific clusters. By reducing variations in your infrastructure, you reduce your maintenance cost and attack surface. Also, having policies codified enables the automation of common tasks and thus improves efficiency at an organizational level since you get to prevent bad setup and configuration from leaking into your production environment.
The policies you want to enforce come from your organization’s established guidelines or agreed-upon conventions, and best practices within the industry. It could also be derived from tribal knowledge that has accumulated over the years within your operations and development teams.
Policies could be established for multiple areas of your operational environments. You want your Kubernetes clusters to be reliable and secure and you want to control who has access to what. You also want to limit the usage of available infrastructure resources and enforce some quotas.
Additionally, you want to enforce rules for your network ingress and egress traffic. In this section, we will cover some examples of policies you might want to enforce on top of Kubernetes. This should be regarded as a starting point and is not intended to be a complete or comprehensive list.
You want to ensure and improve the continuity of your business applications. This is done by making your system highly available and fault-tolerant. Here are some examples of policies you can enforce in your Kubernetes clusters:
afinity.podAntiAfinityis set in your deployment spec to avoid having multiple pods - from the same deployment - running on the same node.
livenessProbeare defined in your container’s spec to guarantee that only healthy pods get traffic.
Define rules and conditions related to access and privilege that pods must meet to be allowed to run in your cluster. For example:
mustRunAsNonRootso the container and its child process cannot escalate their privilege or change their capabilities.
read-onlyaccess to the filesystem by ensuring that
Check that best practices are applied and your network rules are followed for ingress and service objects defined in your cluster:
hostNetworkfor any pod since this could limit the number of places the pod could run, since
hostIP.hostPort.protocolcombination must be unique. Additionally, avoid using
hostNetwork(for the same reason).
selector.k8s-appis limited to certain (necessary) controllers.
Implement role-based access control and enforce your policies:
RoleBindingobjects give patch access to users that you haven’t approved.
rules.verbscombinations that might violate any of your access control policies.
General best practices that you’ll want to maintain across your cluster, or for certain types of workloads:
metadata.labelsfor all your
StatefulSet(like an owner name or email).
container.imagein all your specs are using a trusted container registry.
container.image with the
:latesttag. Force the use of specific versions.
Again, these were simply a few examples of areas where you can implement some policies for your Kubernetes clusters. At Magalix, we’ve already implemented most of these policies so you can have a basic PaC framework out of the box for your organization, which you can also expand and customize as you see fit.
There are three key dimensions that need to be defined in order to establish a Policy-as-Code framework within your organization:
Once you have the targets, policies, and triggers defined, you need a way to enforce them to ensure compliance. Doing so manually is a sure way to put your organization in firefighting mode incessantly. The best way to implement this framework is to use tools that can automate the compliance check process based on the triggers you defined, as well as provide a user-friendly way to manage the policies and their targets.
As part of the CNCF project, the Open Policy Agent (OPA) is a great tool that allows organizations to easily define custom policies for their Kubernetes environments. Open Policy Agent policies are written in a declarative policy language called Rego.
With Rego, you can filter the input (workloads, users, other entities) to match the “targets” you want and you can add assertions that would define your “policy.” It’s important to have a common framework and tools to enforce your policies so that you can easily evolve your policies and enforce them consistently within your different operations environments.
While it is possible to install and configure your own setup of OPA, that would require a much higher degree of know-how, effort, and maintenance.
Magalix allows you to define and manage these policies, and their lifecycle, in an easy and user-friendly way. Internally, Magalix uses OPA as the policy execution engine. Magalix, by default, will run global policies based on Kubernetes’ best practices for the relevant Kubernetes objects in your cluster.
Also, it will allow you to define custom policies (KubeAdvisor), run these policies periodically against your cluster, and track violations and compliance overtime to report regular updates (via a dashboard or through integrations with Slack, etc.).
Additionally, Magalix offers webhooks that you can use to pass your object specs, and we’ll run all relevant policies and respond to you with any violations. You’ll find this is a great way to integrate your CI/CD pipeline, and easily prevent policy violations. To read about Magalix Policy-as-Code platform for Kubernetes, go to Kubernetes Governance with Magalix.
Book a commitment free consultation with a Magalix expert now!
Self-service developer platform is all about creating a frictionless development process, boosting developer velocity, and increasing developer autonomy. Learn more about self-service platforms and why it’s important.
More and more businesses are adopting GitOps. Learn about the 5 reasons why GitOps is important for businesses.