Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

doc: TRG 4.07: Read-Only Filesystem (DRAFT) #414

Merged
merged 20 commits into from
Nov 22, 2023
Merged
Changes from 17 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
94 changes: 94 additions & 0 deletions docs/release/trg-0/trg-4-07.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,94 @@
---
title: TRG 4.07 - Read-only filesystems
---

:::caution
Proposed release date: 01st of Nov 2023
:::

| Status | Created | Post-History |
|------------|--------------|----------------------------------------|
| Draft | 03-Octo-2023 | Initial contribution |

## Why

The read-only root filesystem right can limit the impact of container compromise when set properly.
This can prevent malicous processes or applications from writing back to the host file system.
Such a setting can be an extra protection layer to prevent an attack.

## Description

The read-only filesystem configuration is defined in the deployment yaml. The security context parameters are assigned to the pod.
This ensures that unpriviledged access cannot be abused to install malicous software of write to the file system. This control is by default false.
Therefore it is to be considered for each deployment if the flag can be set to the recommended value "true". Only read in this case.

### Implementation

The container's **Pod resource file (yaml)** has to be modified to set rights to read-only.

Mounts the container's root filesystem as read-only:

```yaml
apiVersion: v1
kind: Pod
metadata:
name: read-only
spec:
containers:
...
# The [container security context](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-the-security-context-for-a-container) defines privilege and access control settings for a Container within a pod
securityContext:
capabilities:
# -- Specifies which capabilities to drop to reduce syscall attack surface
drop:
- ALL
# -- Specifies which capabilities to add to issue specialized syscalls
add: []
# -- Whether the root filesystem is mounted in read-only mode
readOnlyRootFilesystem: true
# -- Controls [Privilege Escalation](https://kubernetes.io/docs/concepts/security/pod-security-policy/#privilege-escalation) enabling setuid binaries changing the effective user ID
allowPrivilegeEscalation: false
# -- Requires the container to run without root privileges
runAsNonRoot: true
# -- The container's process will run with the specified uid
runAsUser: 10001
```

Checkout these great Tractus-X template examples.

K8s Deployment:

[EDC Security Context 1](https://github.com/eclipse-tractusx/tractusx-edc/blob/112fc6e86202ce6a64a88142899a425abfbfd364/charts/tractusx-connector/templates/deployment-controlplane.yaml#L54-L55)

[EDC Security Context 2](https://github.com/eclipse-tractusx/tractusx-edc/blob/112fc6e86202ce6a64a88142899a425abfbfd364/charts/tractusx-connector/templates/deployment-controlplane.yaml#L81-L82)

Values.yaml:

[EDC Security Context 3](https://github.com/eclipse-tractusx/tractusx-edc/blob/112fc6e86202ce6a64a88142899a425abfbfd364/charts/tractusx-connector/values.yaml#L145-L155)

[EDC Security Context 4](https://github.com/eclipse-tractusx/tractusx-edc/blob/112fc6e86202ce6a64a88142899a425abfbfd364/charts/tractusx-connector/values.yaml#L156-L171)

### Temporary Folders (If needed)

A temporary filesystem (tmpfs) works similiar like a regular volume. Everything written to this filesystem will is removed when the container gets terminated.
SSIRKC marked this conversation as resolved.
Show resolved Hide resolved
In the case that an executable in your container should need a temporary folder for logging or spooling purposes, you can mount a writable emptydir volume as follows:

```yaml
apiVersion: v1
kind: Pod
metadata:
name: temporary-folder
spec:
containers:
- name: sample-container-which-needs-temporary-folder
image: your-image
securityContext:
readOnlyRootFilesystem: true
volumeMounts:
- name: tempfolder
mountPath: /tmp
readOnly: false
volumes:
- name: tempfolder
emptyDir: {}
```