From fe2aa34977186ae6077b34d107e12f473d97a003 Mon Sep 17 00:00:00 2001 From: Maciej Lebiest Date: Sat, 9 Nov 2024 15:04:29 +0100 Subject: [PATCH] initial commit, secrets WiP --- README.md | 117 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 117 insertions(+) create mode 100644 README.md diff --git a/README.md b/README.md new file mode 100644 index 0000000..28dc186 --- /dev/null +++ b/README.md @@ -0,0 +1,117 @@ +# Securing Linux Containers + +## Table of contents + + +- [Securing Linux Containers](#securing-linux-containers) + - [Table of contents](#table-of-contents) + - [Introduction](#introduction) + - [Secrets](#secrets) + - [Alternatives](#alternatives) + - [Files](#files) + - [Users and groups](#users-and-groups) + - [Filesystem](#filesystem) + - [Resources limits](#resources-limits) + - [Network](#network) + - [Images](#images) + - [Building](#building) + - [Scanning](#scanning) + - [Selinux](#selinux) + + +## Introduction + +This document is a collection of simple and very generic tips and best +practices related to seciurity of Linux containers. Contenerization is +considered safer by default, but then one can hear about discovered +vulnerabilities that are primarly bad for applications in containers +(Example: [CVE-2023-49103](https://nvd.nist.gov/vuln/detail/CVE-2023-49103)). +Tips and best practices collected here should help raise awarness about +how to keep containers really secure. Contents are kept container-engine +agnostic, but examples will be based on actual implementations (Podman, k8s). + +## Secrets + +Secret is the most vulnerable data, as it usually can open access to other +private data. They might also allow modification of the environment, which +means possibilities for further access or many other forms of attack. + +> [!WARNING] +> Don't use environment variables for secrets + +Container isolation made providing and managing secrets somewhat harder, as +they need to cross the additional barier. This casued the rather dangerous +trend of providing secrets among many other configuration data in form of +environment variables. At first sight it might look like good idea, but when +actually compared to other means of storing secrets it turns out that +environment variables might be much easier to access by attacker, than +for example arbitrary files. [CVE-2023-49103](https://nvd.nist.gov/vuln/detail/CVE-2023-49103) +is only an example of vulnerability which was considered to be more +dangerous for contenerized apps, because of the vulnerability +being based on gaining access to env variables. + +### Alternatives + +#### Files + +Files with secrets are common and broadly supported. With proper setup they can +be also very secure. + +- Keep configuration and secret files on entirely different path than other data +- If application runs main process under different user than worker processes +(which usually have direct contact with user interaction), the configuration +should not be readable by the worker process user. +- Depending on the technology used, storage of the secret files inside of a +container could be temporary/volatile. In kubernetes Secret objects are mounted +as tmpfs. Example for mounting secret as tmpfs in pod: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: app +spec: + containers: + - name: app + image: registry.fedoraproject.org/fedora-minimal:latest + command: [ "sleep", "infinity" ] + volumeMounts: + - mountPath: /config + name: config + volumes: + - name: config + secret: + secretName: config +``` + +This produces readonly tmpfs mount inside: + +```bash +bash-5.2# df -h /config/ +Filesystem Size Used Avail Use% Mounted on +tmpfs 4.8G 4.0K 4.8G 1% /config + +bash-5.2# ls -la /config/ +total 0 +drwxrwxrwt. 3 root root 100 Nov 9 14:00 . +drwxr-xr-x. 1 root root 24 Nov 9 14:00 .. +drwxr-xr-x. 2 root root 60 Nov 9 14:00 ..2024_11_09_14_00_47.4065932771 +lrwxrwxrwx. 1 root root 32 Nov 9 14:00 ..data -> ..2024_11_09_14_00_47.4065932771 +lrwxrwxrwx. 1 root root 18 Nov 9 14:00 secret.conf -> ..data/secret.conf +``` + +## Users and groups + +## Filesystem + +## Resources limits + +## Network + +## Images + +### Building + +### Scanning + +## Selinux