Auto-discovery of K8s security policies: The problem we’re trying to solve

Setting up security for existing workloads is hard – because writing policies that understand the application behavior while still providing a zero trust environment is a non-trivial problem.

More often than not, application developers as well as security engineers do not  necessarily know the entire behavior of an application especially when it is already running in production; and the application behavior is not well understood especially in brownfield environments.

This makes it difficult to onboard security tools like Accuknox, as complex application workloads have a steep learning curve for the network security engineers / devsecops teams because of which they tend to take shortcuts in defining a broad perimeter based security approach (which unfortunately doesn’t work in cloud environments).

Automated policy discovery for a ZERO Trust environment

The best way to generate policies for existing workloads is by observing the behavior of the application itself, especially when it is running in a safe, staging like environment where production style workloads can be replicated without providing exposure of the application to external threat actors.

If that is not an option then policy generation can be done with production workloads as well.

Accknox Auto Discovery Solution enables security teams and developers to auto generate application security policies for network and application behavior instantly in the form of usable policies

How does this work?

Upon the installation of the agents (Kubearmor, and Cilium) – Accuknox auto discovery kicks in for any onboarded cluster. The feeder service is a service that collects application logs and pushes them to a central control plane.

The central control plane then discovers, aggregates and stores the policies in a github / db enabling version-controlled policies.

The Accuknox Auto Discovery system mainly generates two kinds of policies:

Application protection policies for Kubearmor which relate to setting up of

• Mandatory Access Controls to Kubernetes Pods when they are  interacting
  with specific paths of the operating system,
• forking processes,
• opening network calls and
• other resource requests to the operating system.

Network policies for Cilium, which can be applied to the Kubernetes Clusters, pods, nodes using their selector labels. Network policies could be either an Ingress or an Egress policy and could include rules based on following:

• L3/L4 policies based on Ports, Protocol, CIDR/IP-mask, FQDNs, Service names
• L7 policies based on HTTP parameters (Method, URL, Headers), DNS

Figure: Auto Discovered policies

Use cases: K8s Auto-hardening:

• Use-case-1: Limit root file system access
• Many containers have access to root file system via volumeMounts
• By default, k8s enables write access to those paths
• Possible to specify securityContext to make it readOnly
• However, app devs rarely do that
• And security team is not sure about it.
• Proposition: Based on the runtime writes in the volumeMounted paths, discover whether the writeAccess should be disabled and propose a auto-discovered policy.
• Proposition: Based on the runtime read/writes, discover paths of interest to the container and discover policy to restrict access to those paths only.
• Ref: NSA K8s-Hardening-Guidance Appendix B
• Use-case-2: Drop capabilities
• Many containers might require specific caps only
• But devs might enable all the caps
• Possible to drop capabilities using PodSecurityPolicy
• However, difficult for security team to do it since they might not have enough application understanding.
• Proposition: Auto-discover required capabilities and drop rest all. Show the context in which those caps were used. For e.g, raw-sock socket was opened with so-n-so parameters.

Visibility Use-Cases

• Kafka Observability/Monitoring
• Get producer/consumer usage patterns
• Alert based on access to a particular topic
• Auto-discover kafka policies
• Generate least-permissive policy settings for topic consumption.
• Policies could be enforced on producer/consumer

Policy as code

Accuknox’s auto discovery of policy generates both application and network protection policies as code in a git repository and this lends itself well to the git-ops workflow. All policy changes are essentially git commits with approvals being pull requests.

Only the users with the right permissions will be able to merge pull requests on the git repo, or approve policy change requests on Accuknox UI can actually apply policies on the cluster.

A detailed policy audit trail is available in the console Ÿwhere every single change in the policy is documented along with the time

Accuknox’s auto discovery of policies enables enterprises to quickly setup and create policies for existing workloads without having to manually create these policies.

The Roadmap ahead

Accuknox has an exciting roadmap ahead for auto discovery of security policies including

• Identifying identity of the services and attaching them to policies
• Granular application firewall (i.e. Kubearmor) security policies including
  capabilities required.
• Identifying well known workloads (like Kafka) and generating requisite
  allowable / deny policies for the same
• Sec-comp based security policies.

Get in touch

To learn how you can setup security for your cloud workload, reach out to us using the contact us button.

Now you can protect your workloads in minutes using AccuKnox, it is available to protect your Kubernetes and other cloud workloads using Kernel Native Primitives such as AppArmor, SELinux, and eBPF.

Let us know if you are seeking additional guidance in planning your cloud security program.