sysdiglabs / kube-apparmor-manager

Manage AppAmormor profiles for Kubernetes cluster

kube-apparmor-manager

Manage AppArmor profiles for Kubernetes cluster

Behind the Scenes

• AppArmorProfile CRD is created and AppArmorProfile objects are stored in etcd.
• Actual AppArmor profiles will be created(updated) across all worker nodes through synchronizing with AppArmorProfile objects.

AppArmorProfile Object Explained

apiVersion: crd.security.sysdig.com/v1alpha1
kind: AppArmorProfile
metadata:
  name: apparmorprofile-sample
spec:
  rules: |
    # This is the default deny mode of AppArmor profile.
    # List the allow rules here separated by new line character.
    
    # allow few read/write activities
    allow /etc/* r,
    allow /tmp/* rw,

    # allow few commands execution
    allow /bin/echo mrix,
    allow /bin/sleep mrix,
    allow /bin/cat mrix,
  enforced: true # set profile to enforcement mode if true (complain mode if false)

Install as a Krew Plugin

Follow the instructions to install krew. Then run the following command:

kubectl krew install apparmor-manager

The plugin will be available as kubectl apparmor-manager.

Configure Environment

• SSH_USERNAME: SSH username to access worker nodes (default: admin)
• SSH_PERM_FILE: SSH private key to access worker ndoes (default: $HOME/.ssh/id_rsa)
• SSH_PASSPHRASE: SSH passphrase (only applicable if the private key is passphrase protected)

Usage

Usage:
  kube-apparmor-manager [command]

Available Commands:
  enabled     Check AppArmor status on worker nodes
  enforced    Check AppArmor profile enforcement status on worker nodes
  help        Help about any command
  init        Install CRD in the cluster and AppArmor services on worker nodes
  sync        Synchronize the AppArmor profiles from the Kubernetes database (etcd) to worker nodes

Example Output

AppArmor enabled status

$ ./kube-apparmor-manager enabled
+-------------------------------+---------------+----------------+--------+------------------+
|           NODE NAME           |  INTERNAL IP  |  EXTERNAL IP   |  ROLE  | APPARMOR ENABLED |
+-------------------------------+---------------+----------------+--------+------------------+
| ip-172-20-45-132.ec2.internal | 172.20.45.132 | 54.91.xxx.xx   | master | false            |
| ip-172-20-54-2.ec2.internal   | 172.20.54.2   | 54.82.xx.xx    | node   | true             |
| ip-172-20-58-7.ec2.internal   | 172.20.58.7   | 18.212.xxx.xxx | node   | true             |
+-------------------------------+---------------+----------------+--------+------------------+

AppArmor enforced profiles

./kube-apparmor-manager enforced
+-------------------------------+--------+------------------------------------------------------+
|           NODE NAME           |  ROLE  |                  ENFORCED PROFILES                   |
+-------------------------------+--------+------------------------------------------------------+
| ip-172-20-45-132.ec2.internal | master |                                                      |
| ip-172-20-54-2.ec2.internal   | node   | /usr/sbin/ntpd,apparmorprofile-sample,docker-default |
| ip-172-20-58-7.ec2.internal   | node   | /usr/sbin/ntpd,apparmorprofile-sample,docker-default |
+-------------------------------+--------+------------------------------------------------------+

Sync

When ever there is change to AppArmorProfile object, run sync to synchronize across all the worker nodes.

$ ./kube-apparmor-manager sync
**** Host: 54.82.xx.xx:22 ****
** Execute command: echo 'profile apparmorprofile-sample flags=(attach_disconnected) {
	allow /etc/* r,
	allow /tmp/* rw,
	allow /bin/echo mrix,
	allow /bin/sleep mrix,
	allow /bin/cat mrix,
}' > /tmp/apparmorprofile-sample **

** Execute command: mv /tmp/apparmorprofile-sample /etc/apparmor.d/apparmorprofile-sample **

**** Host: 54.82.xx.xx:22 ****
** Execute command: aa-enforce /etc/apparmor.d/apparmorprofile-sample **
Setting /etc/apparmor.d/apparmorprofile-sample to enforce mode.

**** Host: 18.212.xxx.xxx:22 ****
** Execute command: echo 'profile apparmorprofile-sample flags=(attach_disconnected) {
	allow /etc/* r,
	allow /tmp/* rw,
	allow /bin/echo mrix,
	allow /bin/sleep mrix,
	allow /bin/cat mrix,
}' > /tmp/apparmorprofile-sample **

** Execute command: mv /tmp/apparmorprofile-sample /etc/apparmor.d/apparmorprofile-sample **

**** Host: 18.212.xxx.xxx:22 ****
** Execute command: aa-enforce /etc/apparmor.d/apparmorprofile-sample **
Setting /etc/apparmor.d/apparmorprofile-sample to enforce mode.

kube-apparmor-manager's Issues

Node Daemonset

Hello, just found this project and it looks like something that could solve a problem of ours (that being that we want to be able to develop apparmor profiles alongside our applications and have them be updated when we upgrade our app). That said I have a few questions before I start taking a deeper look into it:

• Is this still in the experimental or POC stage? IE, if we start using it is there a good chance that it will continue to be developed and maintained?
• Let's say that I patch an Apparmor CRD in place (like as part of my deployments). Is there a mechanism for something to automatically detect that that profile has been updated and then sync it to the hosts? I assume this would take the form of a daemonset that runs on each node that automatically reloads on-demand.

panic: error configuring SSH client

I tried the kube-apparmor-manager on a linux and mac client but always get the following error:

---

panic: error configuring SSH client, make sure you setup the credentials correctly

goroutine 1 [running]:
main.main()
/home/runner/work/kube-apparmor-manager/kube-apparmor-manager/main.go:19 +0x9dd

---

SSH_PERM_FILE and SSH_USERNAME are specified and working if I use the variables while connecting to one of the worker nodes via ssh.

Why use External IPs to connect to nodes when syncing profiles?

In many scenarios, node does not has an External IP assigned, syncing get failed. I wonder why use External IPs to connect to nodes when syncing profiles?

kube-apparmor-manager/aa/service.go

Line 144 in 6b8ff07

err := aa.sshClient.Connect(node.ExternalIP, SSH_PORT)

apiVersion: apiextensions.k8s.io/v1beta1 deprecated since 1.22

CRD api used is deprecated and needs to be updated from apiextensions.k8s.io/v1beta1 to apiextensions.k8s.io/v1

See Kubernetes deprecation guide:
https://kubernetes.io/docs/reference/using-api/deprecation-guide/

If you run the init command on a newer Kubernetes version, you will get the following error:

---

➜ kubectl apparmor-manager init -i
I0616 11:40:14.451106 55202 k8s.go:77] Creating a CRD: apparmorprofiles.crd.security.sysdig.com
FATA[2023-06-16T11:40:15+02:00] failed to install CRD: the server could not find the requested resource

FATA[2022-01-06T04:06:46-08:00] failed to install AppArmor service: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain

export SSH_USERNAME=root
export SSH_PASSPHRASE=123456
export SSH_PERM_FILE=/root/.ssh/id_rsa

$ kubectl apparmor-manager init
I0106 04:06:46.144739 49894 k8s.go:77] Creating a CRD: apparmorprofiles.crd.security.sysdig.com
FATA[2022-01-06T04:06:46-08:00] failed to install AppArmor service: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain

why?