training/containers
2
0
Fork 0
Code Issues 1 Pull Requests Actions Packages Projects Releases Wiki Activity

Add section about security
Some checks failed
Gitea Actions Demo / Explore-Gitea-Actions (push) Failing after 16s
Details

Browse Source
This commit is contained in:
Marco Verleun
2023-04-21 16:25:06 +02:00
parent 757a2cc608
commit eb0ed998dd
6 changed files with 124 additions and 82 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
slides/index.yaml
View File

@@ -17,7 +17,4 @@
title: Improving container security
lang: nl
#attend: https://enix.io/fr/services/formation/online/
slides: https://training.verleun.org/intro-container-security.yml.html#1
slides: ./intro-container-security.yml.html#1

4
slides/intro-container-security.yml
View File

@@ -1,11 +1,11 @@
title: |
Introduction Container Security
Introduction Container Security and Hardening
#chat: "[Slack](https://dockercommunity.slack.com/messages/C7GKACWDV)"
#chat: "[Gitter](https://gitter.im/jpetazzo/workshop-yyyymmdd-city)"
#gitrepo: github.com/jpetazzo/container.training
slides: https://training.verleun.org/tdose.zip
slides: https://training.verleun.org/slides.zip
#slidenumberprefix: "#SomeHashTag — "
slidenumberprefix: "📜 "

27
slides/secure-containers/cve.md
View File

@@ -1,10 +1,10 @@
# Other improvements
What about security of the code / packages?
- What about security of the code / packages?
Choosing the proper build image might make a big difference:
- Choosing the proper build image might make a big difference:
Look at the following two `Dockerfiles`:
- Look at the following two `Dockerfiles`:
```bash
FROM python:latest
@@ -24,31 +24,35 @@ CMD ["python", "worker.py"]
---
The only difference is the base image. But the end result is quite different:
## The only difference is the base image.
(Scanning is done with `grype`)
- But the end result is quite different:
| Base image | Image size | CVE's |
|---|---|---|
| python:latest | 888 Mb | 1114 |
| python:alpine | 73,5 Mb | 3 |
--
(Scanning is done with `grype` and since the writing of this presentation the numbers have increased)
The 'full' python image has even `gcc` included....
---
## The 'full' python image has even `gcc` included....
```bash
docker run --rm --entrypoint gcc -it python-latest:latest
gcc: fatal error: no input files
compilation terminated.
```
```bash
docker run --rm --entrypoint gcc python-alpine:latest
docker: Error response from daemon: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: exec: "gcc": executable file not found in $PATH: unknown.
```
---
Consider a `multistage build`
## Consider a `multistage build`
```bash
FROM python:latest as builder
@@ -69,12 +73,15 @@ USER 1234
CMD ["python", "worker.py"]
```
- The required code could be build in image 1 and transfered to image 2 leaving the majority of CVE's behind...
---
Result:
## Result multistage build
| Base image | Image size | CVE's |
|---|---|---|
| python:latest | 888 Mb | 1114 |
| python:alpine | 73,5 Mb | 3 |
| python:mulistage | 73,5 Mb | 3 |
| python:multistage | 73,5 Mb | 3 |

22
slides/secure-containers/intro.md
View File

@@ -1,6 +1,6 @@
# Introduction
## Why talk about container security/hardening?
Why talk about container security/hardening?
- Good containers improve system security
@@ -16,17 +16,21 @@ What about this one?
## Hardening is a must nowadays
CIS Benchmarking is a good thing to do:
- CIS Benchmarking is a good thing to do:
- Checkout: https://github.com/docker/docker-bench-security
- Checkout: https://www.cisecurity.org/benchmark/docker and https://github.com/docker/docker-bench-security
- Running `docker` in a non-root environment as well.
- Consider `podman` instead of `docker`
---
## Building images
## Build images as secure as possible
Build them according to the best practices as described here <https://docs.docker.com/develop/develop-images/dockerfile_best-practices/>
- Build them according to the best practices as described here <https://docs.docker.com/develop/develop-images/dockerfile_best-practices/>
Be careful when building `base images`:
- Be careful when building `base images`:
- Due to inherentence labels are transfered from one image to the other
@@ -38,12 +42,12 @@ Be careful when building `base images`:
## What about exising container images?
Do we rebuild them?
- Do we rebuild them?
Can we change the behavior of the container without modifying the image?
- Or can we change the behavior of the container without modifying the image?
--
## Yes we can
Let's see how in the next slides where we will secure a nice demo application
- Let's see how in the next slides where we will secure a nice demo application.

101
slides/secure-containers/possible-improvements.md
View File

@@ -1,20 +1,101 @@
# Possible improvements
The app is running ~~fine~~ (It does what it is supposed to do at least)
- Useful commands when trying to improve images:
```bash
docker logs
docker diff
docker exec ...
trivy
grype
```
---
## What do we know about the app?
- The app is running ~~fine~~
- It does what it is supposed to do at least
--
Some improvement areas:
- Some improvement areas:
- All containers are running with root privileges
- All containers are running with root privileges
- Too many privileges (`man 7 capabilities`)
- Too many privileges (`man 7 capabilities`)
- Root filesystem is writeable
- Root filesystem is writeable
--
- Quite a few CVE's (As a result of the build)
- Quite a few CVE's (As a result of the build)
---
## How to improve the `docker-compose.yml` file
- Let's pretend we do not want to modify the original `docker-compose.yml` file
--
- Changes here might cause issues with upstream updates.
- Hard to keep track of differences with merge conflicts
--
- Let's override values with `docker-compose.override.yml`
```bash
❯ docker-compose ls
NAME STATUS CONFIG FILES
dockercoins running(5) docker-compose.yml,docker-compose.override.yml
```
---
## Two files are merged together
`docker-compose.yml`
```yaml
version: "2"
services:
rng:
build: rng
ports:
- "8001:80"
```
`docker-compose.override.yml`
```yaml
version: "2"
services:
rng:
user: "4242:4242"
```
---
## Combined result
- As shown by `docker-compose config`
```yaml
version: "2"
services:
rng:
build: rng
ports:
- "8001:80"
user: "4242:4242"
```
---
@@ -32,7 +113,7 @@ Some improvement areas:
## Improvement 1
Change user id to 4242. Redis can no longer write to `/data` if a volume exists so we mount a writeable directory on top of it (or just remove the existing volume)
- Change user id to 4242. Redis can no longer write to `/data` if a volume exists from a previous run so we mount a writeable directory on top of it (or just remove the existing volume)
```yaml
services:
@@ -51,7 +132,7 @@ services:
## Improvement 2
Lets reduce capabilities to make sure no weird things can happen
- Lets reduce capabilities to make sure no weird things can happen
```yaml
...
@@ -68,13 +149,13 @@ services:
...
```
It does not show anything different...
- It does not show anything different...
---
## Improvement 3
Make the root filesystem read only
- Make the root filesystem read only
```yaml
...

47
slides/secure-containers/sampleapp.md
View File

@@ -66,50 +66,3 @@ class: pic
![Diagram showing the 5 containers of the applications](images/dockercoins-diagram.png)
---
## How to improve the `docker-compose.yml` file
Let's pretend we do not want to modify the original `docker-compose.yml` file
--
- Changes here might cause issues with upstream updates.
- Hard to keep track of differences with merge conflicts
--
Let's override values with `docker-compose.override.yml`
```bash
❯ docker-compose ls
NAME STATUS CONFIG FILES
dockercoins running(5) docker-compose.yml,docker-compose.override.yml
```
---
## Two files are merged together
`docker-compose.yml`
```yaml
version: "2"
services:
rng:
build: rng
ports:
- "8001:80"
```
`docker-compose.override.yml`
```yaml
version: "2"
services:
rng:
user: "4242:4242"
```