Security Policies for Kubernetes

The concept of creating code in a high-level language to administer and automate rules is known as Policy as Code (PaC). We should impose certain standards for Kubernetes workloads, such as security, configuration, deployment best practices, operational considerations, governance, and compliance.

In a Kubernetes cluster, Kyverno functions as a dynamic admission controller. The kube-apiserver sends Kyverno HTTP callbacks for admission webhooks that are validating and modifying, and it processes these callbacks by applying matching policies to produce results that either enforce admission policies or refuse requests.

Policy Engine by Kyverno

Kyverno, which means "govern" in Greek, is a policy engine made especially for Kubernetes. The attributes are:

• policies as YAML resources for Kubernetes
• Utilizing Kustomize overlays, we can verify, alter, or create any resource.
• matching resources using wildcards and label selectors
• report policy infractions or use admission controls to prevent non-conforming resources

The most popular regulations and best practices were developed by the Kyverno team. There are three distinct sorts of policies.

• Validate

The mandatory characteristics that must be present when creating a specific resource are specified in a typical validation rule. The properties of a newly produced resource are compared by Kyverno to the validate rule when it is created by a user or process. The resource may be generated if those properties are validated, which means there is agreement.

• Mutate

A mutate rule, which is written as either an RFC 6902 JSON Patch or a tactical merge patch, can be used to change matched resources.

Resource mutation happens before resource validation, thus the rules governing validation shouldn't conflict with the adjustments made by the mutation section. Use mutateExisting policies to alter existing resources in addition to those affected by AdmissionReview requests.

• Generate

When a new resource is generated or the source is updated, a generate rule can be used to create extra resources. This is helpful when developing auxiliary materials for a Namespace, such as brand-new RoleBindings or NetworkPolicies.

We can enforce use cases and regulations for Kubernetes deployments.

• Enforce "application name" label in the pod
• Require Limits and Requests
• Add network policy

1. Enforce "Application Name" label in the pod

apiVersion: kyverno.io/v1

kind: ClusterPolicy

metadata:

name: require-labels

spec:

validationFailureAction: enforce

rules:

- name: check-for-labels

match:

resources:

kinds:

- Pod

validate:

message: "The label `app.kubernetes.io/name` is required."

pattern:

metadata:

labels:

app.kubernetes.io/name: "?*"

Create a deployment in pod and apply the policy to the cluster. Make an unlabeled inflate deployment in the cluster. These regulations are of the validation type. Our Kubernetes api objects' specified pattern is validated.

2. Add Network Policy

Kubernetes permits communication between every Pod in a cluster by default. To limit communications, the NetworkPolicy resource and a CNI plug-in that implements NetworkPolicy must be utilized. Each Namespace should have a default NetworkPolicy set up to block all incoming and outgoing traffic to its Pods by default. In order to allow desired traffic to application Pods from certain sources, application teams can then specify additional NetworkPolicy resources. When a new Namespace is formed, this policy will generate a new NetworkPolicy resource called "default-deny" that will block all traffic.

apiVersion: kyverno.io/v1

kind: ClusterPolicy

metadata:

name: add-networkpolicy

spec:

validationFailureAction: enforce

rules:

- name: default-deny

match:

resources:

kinds:

- Namespace

generate:

kind: NetworkPolicy

name: default-deny

namespace: "{https://www.dhirubhai.net/redir/phishing-page?url=%7Brequest%2eobject%2emetadata%2ename}}"

synchronize: true

data:

spec:

# select all pods in the namespace

podSelector: {}

# deny all traffic

policyTypes:

- Ingress

- Egress

3. Monitoring – Dashboard

The Prometheus metrics endpoint exposes Kyverno's metrics. We may display in a Grafana dashboard or scrape the Kyverno metrics. The policy reporter UI in Kyverno can target several channels.

Conclusion

Using OPA, Kyverno, we can strengthen the security posture for our clusters. To design or administer policies, there is no need to learn a new language. It integrates with our current tools, like git, customize, and kubectl. Let's see how AI tools can compliment this workflow in the next blog.

Few good read for Developers, DevOps and DevSecOps teams: