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

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

Figure: Sample Auto Discovered policy for a specific CIDR

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.