Prevention/Blocking for Container Host Security
Problem to solve
As a security analyst, I need to be able to prevent certain activities from occurring (process starts, edits to files, etc.) so that I can ensure that my containers are fully protected from threats.
Intended users
User experience goal
The user will be able to follow GitLab documentation to install AppArmor and Pod Security Policies into their cluster.
Proposal
- The user will be able to follow GitLab documentation to install AppArmor and Pod Security Policies in their Kubernetes cluster and connect it to GitLab
- After installation, the user will be able to do the following:
- Prevent new processes from starting inside a container
- Prevent changes from being made to specified files or paths inside a container
- Prevent new shells/terminals from starting in the container
- Prevent new ports from opening inside the container
Further details
Adding AppArmor and Pod Security Policies is one step toward achieving our broader Container Behavior Analytics strategy and is necessary to allow certain activities to be blocked inside containers.
Permissions and Security
This aligns with the current GitLab permission model.
Documentation
Documentation will be added to inform a user how to install AppArmor and Pod Security Policies into their environment.
Availability & Testing
- Unit tests will be built as appropriate
- AppArmor and Pod Security Policies will be able to be installed together with Falco and Cilium and no product will interfere with the other one or cause undue performance problems
- [as much as time allows] A long-running performance test will be done to verify that there are no memory leaks or other performance problems introduced over time
Proposed solution
- Add AppArmor loader as a gitlab hosted helm chart
- Allow users to add profiles (through AppArmor helm chart) into their k8s
- Allow users to use the existing profiles when deploying their apps (through auto-deploy-values).
Further improvements
As described in this comment, the integration between appArmor on a cluster level (in addition to PSP features) will be tracked by this follow-up issue.
Pod Security Policy covers a wider range of feature which are not exclusive to AppArmor. SELinux and SecComp could be further supported as follow-up issues.
SELinux would expand the usage of Mandatory Access Controls to a wider number of distributions (the ones who do not support AppArmor).
SecComp would allow a possible mapping of syscalls while paired with Falco.
What does success look like, and how can we measure that?
What is the type of buyer?
Is this a cross-stage feature?
Links / references
#216983