KubeArmor Security Self-assessment

Table of contents

Metadata

A table at the top for quick reference information, later used for indexing.

Softwarehttps://github.com/KubeArmor/KubeArmor
Security ProviderYes
LanguagesGo, C(eBPF), Shell
SBOMFOSSA
Docurl
Security fileSECURITY.md
Security Considerations in KubeArmorhttps://github.com/kubearmor/KubeArmor/wiki/Security-Considerations-in-KubeArmor
Optional Security Enhancementshttps://github.com/kubearmor/KubeArmor/blob/main/getting-started/kubearmor-security-enhancements.md

Overview

KubeArmor is a runtime Kubernetes security engine. It uses eBPF and Linux Security Modules(LSM) for fortifying workloads based on Cloud Containers, IoT/Edge, and 5G networks. It provides preemptive mitigation using policy-based controls.

Background

KubeArmor is a runtime security engine for kubernetes and other cloud workloads. Users can harden their workloads, create Zero Trust security posture i.e., allowing specific systems actions and denying rest using KubeArmor security policies. KubeArmor supports inline mitigation for preventing attacks. Due to its versatility, KubeArmor has found its relevance in Edge and 5G Control Plane security scenarios as well.

KubeArmor primarily provides the following key features:

  • Workload Hardening

    KubeArmor provides a set of hardening policies that are based on industry-leading compliance and attack frameworks such as CIS, MITRE, NIST-800-53, and STIGs. These policies are designed to help you secure your workloads in a way that is compliant with these frameworks and recommended best practices.

  • Zero Trust Policies

    KubeArmor is a tool that helps organizations enforce a zero trust posture within their Kubernetes clusters. It allows users to define an allow-based policy that specifies the specific system behavior that is allowed, and denies or audits all other behavior.

  • Network Visibility & Micro-segmentation

    KubeArmor has visibility into the network connections made into or from the pods. It has visibility across socket(), bind(), connect(), accept() calls. KubeArmor can help auto-generate k8s network policy which are enforceable using most of the k8s CNIs (Container Network Interface).

  • Application Behavior

    KubeArmor has visibility into systems and application behavior. KubeArmor summarizes/aggregates the information and provides a user-friendly view to figure out the application behavior.

Architecture

The following diagram shows the logical architecture for KubeArmor. Each major component is described below:

KubeArmor Component Architecture

KubeArmor Architecture

Actors

  1. API Server

    • Interacts with various components through CRDs (e.g., kubearmorconfig and Policy CRDs).
    • Facilitates Namespace Annotations, ConfigMaps, and pod patching operations.

  2. Operator

    • Manages kubearmorconfig CRDs and orchestrates changes to the Daemonsets and Controller components.

  3. Daemonsets

    • Runs on Nodes and interacts directly with the kernel and CRI API.
    • Collects logs and security telemetry for enforcement and analysis.

  4. Controller

    • Responsible for applying patches to pods as part of policy enforcement.

  5. Relay

    • Aggregates logs from Daemonsets and acts as a communication channel between Daemonsets and external tools.

  6. kArmor CLI

    • Client-side tool that communicates with the Relay via gRPC to interact with the system.
    • Uses helm/client-go for deployments.

  7. Kernel

    • Interfaces with the Daemonsets to provide visibility and enforcement capabilities at the system level.

  8. CRI API

    • Exposes container runtime interactions to the Daemonsets for policy application and telemetry.

Actions

  1. Policy Configuration

    • The API Server interacts with the Operator to manage kubearmorconfig CRDs and Policy CRDs.
    • Policy changes are propagated to the Daemonsets, which applies the configuration on the nodes and containers on the respective nodes.

  2. Security Enforcement

    • The Daemonsets interacts with the Kernel through Linux Security Modules and eBPF, CRI API to enforce security policies on nodes and containers.
    • It can monitor system-level activity, apply runtime restrictions, and collect telemetry logs.

  3. Log Aggregation

    • The Daemonsets sends logs and telemetry to the Relay, which aggregates this information for further use.
    • These logs can be accessed via the kArmor CLI, OpenTelemetry or SIEM Integration for analysis.

  4. Pod Patching

    • The Controller, based on policies and configurations, patches pods as required for setting apparmor annotations.

  5. User Interaction

    • Users interact with the system using the kArmor CLI or kubernetes API.
    • It communicates via gRPC with the Relay Service to fetch logs
    • Deployments and runtime configurations are managed using helm or client-go.

  6. Node-Level Enforcement

    • The Daemonsets ensures runtime security enforcement at the node level by interacting with the kernel and CRI API.

Goals

The goal of the KubeArmor project is to help enforce mandatory access controls and provide observability on processes running inside containers or on host, be it Kubernetes or non orchestrated nodes and containers.

Non-goals

KubeArmor is not a general purpose policy engine or a CNI.

Self-assessment use

This self-assessment is created by the KubeArmor team to perform an internal analysis of the project’s security. It is not intended to provide a security audit of KubeArmor, or function as an independent assessment or attestation of KubeArmor’s security health.

This document serves to provide KubeArmor users with an initial understanding of KubeArmor’s security, where to find existing security documentation, KubeArmor plans for security, and general overview of KubeArmor security practices, both for development of KubeArmor as well as security of KubeArmor.

This document provides the CNCF TAG-Security with an initial understanding of KubeArmor to assist in a joint-assessment, necessary for projects under incubation. Taken together, this document and the joint-assessment serve as a cornerstone for if and when KubeArmor seeks graduation and is preparing for a security audit.

Security functions and features

KubeArmor helps enforce mandatory access control and directly interacts with kernel or apparmor subsystem to help achieve this. KubeArmor directly interacts with privileged entities like eBPF and CRI Socket and we have contained KubeArmor by adequate security measures.

  • Threat Modelling
  • OpenSSF Best Practices (Score of 7.9 and Improving)
  • Fuzz Testing
  • Deployment Best Practices
    • Reduced Volume Mount Points
    • Reduced Capabilities
    • Component TLS Communication
    • Seccomp Profile
    • non root containers with supported deployment
  • OCI Hooks
  • Avoid usage of CRI Sockets
  • WIP: Protecting KubeArmor through KubeArmor

Project compliance

KubeArmor does not document meeting particular compliance standards.

Secure development practices

  • Development Pipeline.

    • All code is maintained in Git and changes must be reviewed by at least 2 maintainers and must pass all unit and e2e tests. Code changes are submitted via Pull Requests (PRs) and must be signed. Commits to the main branch are not allowed.
    • All code must pass snyk, CodeQL and go-sec scans

  • Communication Channels. Reference where you document how to reach your team or describe in corresponding section.

  • Ecosystem. How does your software fit into the cloud native ecosystem?

    • KubeArmor provides a way to enforce security in k8s native way by leveraging k8s resource model.
    • KubeArmor has integrations with lots of CNCF and LF Projects including:
      • Helm (Installation)
      • OpenTelemetry
      • OpenHorizon
      • Kubernetes PolicyReported CRD
      • Nephio

Security issue resolution

Security Processes are documented in SECURITY.md

Appendix