Achieve Zero Trust Security For Hetzner Cloud Workloads With AccuKnox

Achieve Zero Trust Security for Hetzner Cloud Workloads with AccuKnox

by Atharva Shah | April 25, 2024

Learn how AccuKnox and KubeArmor help secure workloads running on Hetzner Cloud by enforcing zero trust security policies, facilitating observability with eBPF, and runtime security controls.

Reading Time: 6 minutes

What is Hetzner Cloud?

Hetzner Cloud is a game-changer when it comes to cost-effective cloud infrastructure. They provide servers for a very low price with an easy-to-use interface, allowing users to optimize their cloud spending while maintaining or exceeding performance levels. Previously they were limited to Germany, but now they are spending wings throughout the globe. This blog will go over the steps to provision a server via Hertzner Cloud and secure it using AccuKnox Zero Trust CNAPP tooling.

What is KubeArmor?

KubeArmor is a cloud-native runtime security enforcement system that provides visibility into the system-level application behavior of pods, containers, and nodes (VMs) allowing control over file access, process execution, and networking operations. The AccuKnox CNAPP platform leverages it to generate whitelisting policies automatically to accomplish a zero-trust architecture by blocking the execution of unknown requests before they are executed. To enforce the policies, it makes use of Linux security modules (LSMs) like AppArmor, SELinux, or BPF-LSM. By utilizing eBPF, KubeArmor produces rich warnings and telemetry events that include container, pod, and namespace identities.

How does Accuknox Support Hetzner Cloud?

Hetzner provides Servers / VMs in the below flavors –

Ubuntu
Fedora
Debian
CentOS
Rocky Linux
Alma Linux

KuberArmor supports all of the above VMs, including Alma Linux, and more as per the support matrix.

Through intelligent methods, the AccuKnox Zero Trust CNAPP solution enhances VMs by providing security at the kernel level. AccuKnox harnesses the power of eBPF (Extended Berkeley Packet Filter) for comprehensive observability. This technology enables real-time monitoring and analysis of system activities, including process executions, sensitive asset access, network interactions, security-sensitive system call activities, and much more.

KubeArmor Supported Security Features for Hetzner Cloud

Observability and Monitoring Through eBPF

KubeArmor protects sensitive information (e.g., k8s secrets, x509 certificates) within the container. For instance, you can set up policy rules that allow auditing of any attempts to update the root certificates in any of the certificate file directories (/etc/ssl/, /etc/pki/, or /usr/local/share/ca-certificates/). It offers real-time insights into system behavior, resource use, and application performance by limiting binary execution in containers. It is compatible with eBPF, which allows monitoring for pod and container-based policy enforcement.

Network Microsegmentation

Security is inherently linked to network segmentation, and AccuKnox delivers on this front. It allows isolating workloads, limiting lateral movement, and cutting the attack surface. KubeArmor tackles this in 4 ways:

Cluster-level isolation
Network-level Control
IP-based segmentation
Process-level network restrictions

Workload Hardening through Policy-Based Rules

KubeArmor supports creating policies for enforcing compliances, such as PCI DSS, CIS, NIST, and STIG and others,some of which can be found in the Open Source GitHub Repository for policies. Coupled with the ability to customize policies, KubeArmor can help implement customized compliance controls. These policies help secure workloads and reduce attack surfaces by implementing block-based policies and can also audit access for compliance purposes. They are auto-recommended on the AccuKnox platform and can be easily customized as required. In-line mitigation prevents policy infringement. Businesses may design and enforce tight policies that control application behavior and access rights by using block-based rules, reducing the risk of illegal activities.

Automatic Discovery of Zero Trust Security Posture

Implementing Zero Trust in Hetzner Cloud

AccuKnox platform can simplify the journey to zero trust on Hetzner cloud server clusters. With the help of the observability provided by KubeArmor, AccuKnox identifies the Application Behavior of the workloads in the cluster. This behavior becomes the baseline for the application to perform its normal functions and gets translated into a policy.

For example, consider a nginx container. The only process that requires execution inside the container is nginx. AccuKnox identifies this through KubeArmor observability and auto-generates a policy similar to the one below:

apiVersion: security.kubearmor.com/v1
kind: KubeArmorPolicy
metadata:
name: only-allow-nginx-exec
namespace: default
spec:
selector:
matchLabels:
app: nginx
file:
matchDirectories:
– dir: /
recursive: true
– dir: /etc/nginx/
recursive: true
fromSource:
– path: /usr/sbin/nginx
– dir: /etc/nginx/
recursive: true
fromSource:
– path: /usr/bin/cd
– dir: /etc/nginx/
recursive: true
readonly: true
action: Block
process: Block
matchPaths:
– path: /usr/sbin/nginx
– path: /usr/bin/bash
message: process-based-asset-access
action: Allow

The above policy whitelists only the nginx process and additionally bash for demo purposes. AccuKnox also has the option to turn on file restrictions, in which case you will be able to enforce least permissive access to files as observed in the above policy essentially

Allows access to /etc/nginx only from the nginx binary itself and from the cd binary
For any other process/user it allows only read access

On enforcing this policy in a default deny posture, zero trust is achieved easily by denying the execution of any other process other than the ones listed in the policy. Since we have modified the policy to allow bash, we can test this out by executing inside the pod as demonstrated below.

kubectl exec -it nginx-77b4fdf86c-x7sdm — bash
root@nginx-77b4fdf86c-x7sdm:/# cd /etc/nginx/
root@nginx-77b4fdf86c-x7sdm:/etc/nginx# ls
bash: /usr/bin/ls: Permission denied
root@nginx-77b4fdf86c-x7sdm:/etc/nginx#

So any execution like the ls binary is denied. Alerts with rich telemetry are provided for any of these attempted violations. An example of the alerts provided:

{
“Action”: “Block”,
“ClusterName”: “0-trust”,
“ContainerID”: “20a6333c6a46e0da32b3062f0ba76e9aed4fc5ef51f5ee8aec5b980963cedea3”,
“ContainerImage”: “docker.io/library/nginx:latest@sha256:32da30332506740a2f7c34d5dc70467b7f14ec67d912703568daff790ab3f755”,
“ContainerName”: “nginx”,
“Data”: “syscall=SYS_EXECVE”,
“Enforcer”: “eBPF Monitor”,
“HostName”: “aditya”,
“HostPID”: 70701,
“HostPPID”: 70666,
“Labels”: “app=nginx”,
“NamespaceName”: “default”,
“Operation”: “Process”,
“Owner”: {
“Name”: “nginx”,
“Namespace”: “default”,
“Ref”: “Deployment”
}, “PID”: 444,
“PPID”: 439,
“ParentProcessName”: “/usr/bin/bash”,
“PodName”: “nginx-77b4fdf86c-x7sdm”,
“PolicyName”: “DefaultPosture”,
“ProcessName”: “/usr/bin/ls”,
“Resource”: “/usr/bin/ls”,
“Result”: “Permission denied”,
“Source”: “/usr/bin/bash”,
“Timestamp”: 1696587116,
“Type”: “MatchedPolicy”,
“UpdatedTime”: “2023-10-06T10:11:56.694009Z”,
“cluster_id”: “4291”,
“component_name”: “kubearmor”,
“instanceGroup”: “0”,
“instanceID”: “0”,
“tenant_id”: “167”,
“workload”: “1”
}

It is seen that the above telemetry provided is rich in context, mapping to the particular Kubernetes resources. This telemetry can also be forwarded to other SIEM tools like Splunk and RSyslog for further analysis and forensics through easy integrations.

With the hardest part of zero trust getting automated through AccuKnox, you only need to do a few clicks to enforce zero trust. But zero trust is not a destination, but a journey and AccuKnox stays true to this by allowing automatic updates to the policies which can be done on demand when new functionality is added. Consequently enforcing Zero Trust for all your workloads running on Hetzner cloud.

Recap of Walkthrough Steps

As of April 10, 2024, Hetzner does not provide managed Kubernetes clusters.
A two-node cluster with CX11 servers and the Hetzner cloud network is assembled to test on Hetzner infrastructure.
After making a few minor adjustments to the community documentation, installing Kubernetes requires utilizing the hcloud CLI tool to supply resources.
Resolving SSH problems requires that SSH keys be in the correct directory and that any existing entries from known_hosts be removed.
An IPv4 Floating IP address, a CX11 server instance for the master and worker nodes, and a Hetzner cloud network are all created during the installation process.
Using commands like hcloud network create and hcloud server create, you may build a network, server instances, and a floating IP address as part of the Kubernetes installation process.
There are substitute package repositories available for installation in place of Google’s deprecated Kubernetes Registry.
Kubernetes package installation entails setting up directories, installing packages with apt-get, and upgrading GPG keys.
The cluster is configured with KubeArmor and a sample workload installed. Suggested policies are generated and implemented to the workloads.
Version conflicts in Kubernetes are handled by indicating the version in kubeadm c, and SSH connects to nodes using public IP addresses.
YAML configuration is used to construct Kubernetes secrets, and scp is used to copy the control-plane kubeconfig to the local environment.
Using the output from the control plane terminal, worker nodes are connected to the cluster, and a test and deploy version of an application is carried out.
Successful enforcement of KubeArmor policies guarantees the security of the deployed workloads.

Must read articles

You cannot secure what you cannot see.

Your most sensitive information is stored on cloud and on premise infrastructure. Protect what is most important from cyber attacks. Real-time autonomous protection for your network's edges.

Ready to get started?

EXPLORE SYNERGIES

	Initially, the attacker has write permission and updates files inside the /etc/ssl directory, demonstrating a lack of security restrictions.
	After applying a KubeArmor security policy, the same action of trying to update a file within the /etc/ssl directory resulted in a “permission denied” error.
	This showcases KubeArmor’s ability to enforce strict access controls and prevent unauthorized modifications to sensitive system files and directories.