Is your Cloud Native Application Secure?

Description

The first thing we do when we learn a new technology is to get things up and running. There are so many things to learn and it's hard enough for us to just wrap our heads around the concepts. Add in all the complexity of cloud native and we can quickly see why there are about one million compromised Kubernetes clusters in the wild.

One of the biggest problems in this area is lack of education. It is assumed that Kubernetes is secure out of the box and this is just not true. This article will hopefully, help in highlighting some of the security vulnerabilities inherent in Kubernetes and how to remediate them.

Insecure by Default

• Typical insecure default configurations of managed Kubernetes clusters include:

• Using default account credentials to access the cluster API

• Containers running unmasked, granting them complete access to a node’s procedures (/proc). This can allow malicious access to kernel parameters at runtime, or retrieval of sensitive information stored on the host.

• Insecure volume configuration leading to leakage of information about other containers in the cluster

Below illustrates some of the components available to help you secure your cloud native app.

Security Context

The following is taken from the Kubernetes Docs
https://Kubernetes.io/docs/tasks/configure-pod-container/security-context/

Configure a Security Context for a Pod or Container
A security context defines privilege and access control settings for a Pod or Container. Security context settings include, but are not limited to:

Discretionary Access Control: Permission to access an object, like a file, is based on user ID (UID) and group ID (GID).

Security Enhanced Linux (SELinux): Objects are assigned security labels.

Running as privileged or unprivileged.

Linux Capabilities: Give a process some privileges, but not all the privileges of the root user.

AppArmor: Use program profiles to restrict the capabilities of individual programs.

Seccomp: Filter a process's system calls.

allowPrivilegeEscalation: Controls whether a process can gain more privileges than its parent process. This bool directly controls whether the no_new_privs flag gets set on the container process. allowPrivilegeEscalation is always true when the container:

• is run as privileged, or has CAP_SYS_ADMIN
• readOnlyRootFilesystem: Mounts the container's root filesystem as read-only.

The above bullets are not a complete set of security context settings -- please see SecurityContext for a comprehensive list.

In practice

(taken from Kubernetes docs - https://Kubernetes.io/docs/tasks/configure-pod-container/security-context/)

Below is an example of what a security context policy looks like:

apiVersion: v1

kind: Pod

metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
  volumes:
  - name: sec-ctx-vol
    emptyDir: {}
  containers:
  - name: sec-ctx-demo
    image: busybox:1.28
    command: [ "sh", "-c", "sleep 1h" ]
    volumeMounts:
    - name: sec-ctx-vol
      mountPath: /data/demo
    securityContext:
      allowPrivilegeEscalation: false

In the configuration file, the runAsUser field specifies that for any containers in the Pod, all processes run with user ID 1000. The runAsGroup field specifies the primary group ID of 3000 for all processes within any containers of the Pod. If this field is omitted, the primary group ID of the containers will be root(0). Any files created will also be owned by user 1000 and group 3000 when runAsGroup is specified. Since fsGroup field is specified, all processes of the container are also part of the supplementary group ID 2000. The owner for volume /data/demo and any files created in that volume will be Group ID 2000.

Managing Security Context in bulk

Creating security context and applying it to a single cluster is relatively easy. What happens when we need to apply it on multiple clusters over multiple pods/containers? It just so happens that there are many tools that make this process a lot easier. Below is a solution we have that allows you to set policy and apply it to multiple Kubernetes clusters, pods and containers.

Handle Security by Policy

The first thing you will notice is that you can see the policy of your pods/containers by just clicking on one.

The second screen illustrates baseline policy that can be deployed based on standard guidelines. You can also duplicate the policy and/or create your own here.

The real power comes in the form of a policy advisor, illustrated below in which the application analyzes the pods/containers and provides recommendations on the correct policy.

Lastly, the solution has a central policy that allows you to define the standard policy that includes elements around security context API security and vulnerabilities. We will discuss vulnerabilities and API security in our upcoming articles.

If you are interested in securing your cloud native workloads then try out Panoptica at Panoptica.app. There is a free tier that is always free!

Additionally, check out our Open Source in this area:

OpenClarity (https://openclarity.io/) - the first open-source solution that forms a cloud native application protection platform. Security needs to shift left into your development pipeline. OpenClarity allows you to understand and manage vulnerabilities and security configuration of Kubernetes, Serverless and APIs.

• KubeClarity – Understand your software bill of materials (SBOM) and the vulnerabilities within. Scan and understand results from different CI stages and detect vulnerabilities in different stages of deployment. Group scanned resources (images/directories) under defined applications to navigate the object tree dependencies (applications, resources, packages, vulnerabilities)
• APIClarity – Analyzes the API endpoint to illustrate intended usage, deprecated API calls, and undocumented features. Additionally, executes trace analyzers fuzzers and BFLA detection to detect potential security threats such as Broken Object Level Authorizations (BOLA), Broken Function Level Authorization(BFLA), and other security issues.
• FunctionClarity - a code integrity solution for serverless functions. It allows users to sign their serverless functions and verify their integrity prior to their execution in their cloud environments. FunctionClarity includes a CLI tool, complemented by a "verification" function deployed in the target cloud account. The solution is designed for CI/CD insertion, where the serverless function code/images can be signed and uploaded before the function is created in the cloud repository.