Prevention/Blocking for Container Host Security (#218441) · Issues · GitLab.org / GitLab

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

Sam (Security Analyst)

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).
Allow users to add Pod Security Policies (which might be associated to a AppAmor profile or not) into their k8s.
Allow users to use the existing PSP.

Further improvements

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?

GitLab Ultimate

Is this a cross-stage feature?

Links / references

#216983 (closed)

### 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

<!-- Who will use this feature? If known, include any of the following: types of users (e.g. Developer), personas, or specific company roles (e.g. Release Manager). It's okay to write "Unknown" and fill this field in later.

Personas are described at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/

* [Cameron (Compliance Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#cameron-compliance-manager)
* [Parker (Product Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#parker-product-manager)
* [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead)
* [Presley (Product Designer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#presley-product-designer)
* [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer)
* [Devon (DevOps Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer)
* [Sidney (Systems Administrator)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator)
* [Sam (Security Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sam-security-analyst)
* [Rachel (Release Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#rachel-release-manager) 
* [Alex (Security Operations Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#alex-security-operations-engineer)
* [Simone (Software Engineer in Test)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#simone-software-engineer-in-test)
* [Allison (Application Ops)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#allison-application-ops) 
* [Priyanka (Platform Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#priyanka-platform-engineer)
* [Dana (Data Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#dana-data-analyst)
-->
* [Sam (Security Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sam-security-analyst)

### 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](https://about.gitlab.com/direction/defend/container_behavior_analytics/) and is necessary to allow certain activities to be blocked inside containers.

### Permissions and Security

This aligns with the current GitLab permission model.

### Documentation

<!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/workflow.html#for-a-product-change

* Add all known Documentation Requirements in this section. See https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements
* If this feature requires changing permissions, update the permissions document. See https://docs.gitlab.com/ee/user/permissions.html -->
Documentation will be added to inform a user how to install AppArmor and Pod Security Policies into their environment.

### Availability & Testing

<!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier.

What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing?

Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance.
* Unit test changes
* Integration test changes
* End-to-end test change

See the test engineering planning process and reach out to your counterpart Software Engineer in Test for assistance: https://about.gitlab.com/handbook/engineering/quality/test-engineering/#test-planning -->
* 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).
 - [ ] Allow users to add Pod Security Policies (which might be associated to a AppAmor profile or not) into their k8s.
 - [ ] Allow users to use the existing PSP.

### Further improvements

[Pod Security Policy](https://kubernetes.io/docs/concepts/policy/pod-security-policy/#policy-reference) covers a wider range of feature which are not exclusive to [AppArmor](https://gitlab.com/apparmor/apparmor/-/wikis/Policy_Layout). 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?

~"GitLab Ultimate"

### Is this a cross-stage feature?

### Links / references
\#216983

Edited May 27, 2020 by Sam White

Discussion
Designs