v1.3.0 Release Blog
KubeArmor is an open-source Kubernetes security enforcement solution that ensures the security of your Kubernetes workloads by enforcing custom security policies. This blog post covers the exciting new features and enhancements introduced in the latest KubeArmor v1.3.0 release. We've made significant improvements to enhance the security, usability, and performance of KubeArmor, making it an even more powerful and robust solution for securing your Kubernetes clusters.
KubeArmor Operator as the Default Installation Method
Capabilities Enforcement with BPF LSM
Execname Matching in KubeArmor Policies
Secure gRPC Communication with Mutual TLS
Additional Columns for KubeArmor Policies
- KubeArmor Operator is now the default installation method for KubeArmor, providing a more streamlined installation process.
- New features include support for capabilities enforcement using BPF LSM, execname matching in policies, and additional columns in KubeArmor Security Policies (KSPs) and Host Security Policies (HSPs).
- Security enhancements include securing KubeArmor itself with Seccomp profiles and implementing mutual TLS (mTLS) for secure gRPC communication
- Support for Alibaba Cloud deployments has been added.
- Performance improvements include filtering watched nodes and pods server-side to reduce overhead in large clusters.
Previously, installing KubeArmor required manual steps and could be a complex process, especially for users unfamiliar with Kubernetes operators. This complexity posed a barrier to adoption and made it challenging to maintain and upgrade KubeArmor installations. To address this issue, the KubeArmor Operator is now the recommended way to install KubeArmor. The karmor install command internally uses the KubeArmor Operator's Helm chart, enabling a more streamlined and operator-based installation process. This change also affects the karmor uninstall command, which now relies on the KubeArmor Operator for uninstallation. By leveraging the KubeArmor Operator, users can benefit from a simplified installation and management experience, as well as take advantage of the operator's capabilities for automated deployments, upgrades, and lifecycle management.
In Kubernetes environments, certain workloads may require specific capabilities to function correctly. However, granting unnecessary capabilities can introduce security risks and potentially expose your cluster to vulnerabilities. Previously, KubeArmor lacked the ability to enforce policies around capabilities, making it challenging to strike the right balance between security and functionality. To address this limitation, KubeArmor now supports enforcement of capabilities rules using the CAPABLE hook in the BPF LSM (Linux Security Module). This feature allows you to define policies that restrict or allow specific capabilities for your workloads, enhancing the overall security posture of your Kubernetes cluster. With capabilities enforcement, you can granularly control which capabilities are granted to your workloads, ensuring that they only have the necessary privileges to function as intended, while minimizing potential security risks.
Identifying and blocking malicious or unauthorized applications running in your Kubernetes cluster can be a challenging task, especially when dealing with dynamic or obfuscated binaries. Previously, KubeArmor relied solely on file paths or other attributes to define policies, limiting its ability to detect and prevent the execution of specific binaries. To address this limitation, KubeArmor now supports matching executable names in its policies. This new feature enables you to create rules based on the name of the executable binary, allowing for more granular control over the applications running in your Kubernetes cluster. For example, you can now block or allow specific crypto-mining binaries like xmrig by matching their executable names. By introducing execname matching, KubeArmor provides an additional layer of security and control, enabling you to proactively detect and prevent the execution of known malicious or unauthorized binaries within your Kubernetes environment.
As a security solution, it's crucial for KubeArmor itself to adhere to security best practices and minimize its attack surface. In previous versions, KubeArmor required the cluster-admin role, which granted broader permissions than necessary, potentially increasing the risk of unauthorized access or privilege escalation. To address these concerns, KubeArmor has undergone significant security enhancements in this release. First, KubeArmor now uses Seccomp profiles to restrict the system calls it can execute, reducing its attack surface and ensuring it follows security best practices. KubeArmor no longer requires the cluster-admin role, further limiting its permissions and adhering to the principle of least privilege. This change reduces the potential impact of a compromised KubeArmor deployment and aligns with security best practices for Kubernetes deployments. All critical vulnerabilities across KubeArmor images have been addressed, ensuring the overall security of the KubeArmor deployment and protecting against potential exploits or vulnerabilities.
In previous versions of KubeArmor, communication between the KubeArmor server and clients (e.g., kubearmor-relay) was unencrypted, potentially exposing sensitive information or allowing unauthorized access to the communication channel. To address this security concern, KubeArmor now supports secure gRPC communication between the KubeArmor server and clients using mutual TLS (mTLS) with self-signed certificates. This enhancement ensures that all communication between KubeArmor components is encrypted, providing a supplementary layer of security for your Kubernetes cluster. By implementing mTLS, KubeArmor mitigates the risk of eavesdropping or man-in-the-middle attacks, ensuring that sensitive information transmitted between KubeArmor components remains confidential and secure.
Previously, when listing KubeArmor Security Policies (KSPs) and Host Security Policies (HSPs) using kubectl get, users only had access to limited information about each policy, making it challenging to quickly assess the purpose and impact of each policy. To improve visibility and usability, KubeArmor now includes additional columns when listing policies. These columns display the action (e.g., allow or block) and severity level for each policy, providing better visibility into your security policies at a glance. This enhancement allows users to quickly identify the intended behavior and potential impact of each policy, facilitating easier policy management and enabling more informed decision-making when deploying or updating security policies within their Kubernetes environment.
As Kubernetes adoption continues to grow, organizations are increasingly leveraging various cloud providers to host their deployments. Previously, KubeArmor lacked official support for Alibaba Cloud deployments, which could pose challenges for users seeking to secure their Kubernetes workloads running on Alibaba Cloud's infrastructure. To address this gap, KubeArmor now officially supports Alibaba Cloud deployments, including Alibaba Cloud Kubernetes (ACK) and Elastic Compute Services (Virtual Machines). This support ensures that KubeArmor can be seamlessly deployed and integrated with Alibaba Cloud environments, providing robust security for your Kubernetes workloads running on Alibaba Cloud. With this addition, KubeArmor expands its reach and enables organizations leveraging Alibaba Cloud to benefit from its advanced security capabilities, ensuring consistent protection across various cloud platforms. The latest image of Alibaba Cloud Linux 3 contains BPF-LSM enabled by default as part of the kernel config but not enabled by default as part of the boot parameter. Thus the user has to enable the bpf-LSM boot parameter for all the nodes for which they desire that the enforcement should work. This (and this for k8s) FAQ helps user with enabling bpf-lsm for VM and k8s env.
In large-scale Kubernetes deployments with numerous nodes and pods, the overhead associated with listing and watching all resources can significantly impact performance and scalability. Previously, each KubeArmor DaemonSet pod listed and watched every node and pod in the cluster, leading to potential performance bottlenecks and resource constraints as the cluster grew larger. To address this performance concern, KubeArmor now filters watched nodes and pods server-side, reducing overhead significantly in large clusters. Instead of each KubeArmor DaemonSet pod listing and watching every node and pod in the cluster, KubeArmor now specifies the nodes and pods of interest for each DaemonSet. This optimization enhances the overall performance and scalability of KubeArmor in large-scale Kubernetes deployments, ensuring efficient resource utilization and enabling smoother operations in resource-constrained environments.
The KubeArmor v1.3.0 release introduces a wealth of new features, security enhancements, and performance improvements. With the introduction of capabilities enforcement, execname matching, secure gRPC communication, and improved visibility into security policies, KubeArmor has become an even more powerful and comprehensive solution for securing your Kubernetes clusters. The support for Alibaba Cloud deployments and performance optimizations ensure that KubeArmor can be effectively deployed and scaled in various environments, including large-scale Kubernetes clusters. We encourage you to upgrade to KubeArmor v1.3.0 and explore these new features and enhancements to further strengthen the security posture of your Kubernetes deployments.
