Lab 6.6 security-review1.yaml intended solution

Version: 2022-11-23
I was able to find out the userid that nginx uses by default, fix the problem with cache, but was not able to figure out (without trying to google) how I get rid of the could not bind port 80 error. Also my tries with capabilities failed, since finding out which would be needed requires research again.
My intuition tells me running the pod as root cannot be the correct solution, what am I missing.
Best Answers
-
Hello @bulldog98
Few take away from the security-review1.yaml
In the yaml, we use security context "runAsUser" at the Pod Spec and also at the container level. What we define at the container level takes precedence. In this case it will run as user 3100.
But, the pod creation is failing... The reason is the nginx image is built to run as root. It needs write access to /etc/nginx to create the conf file and also /var to create a cache file.
We know running as root is not good, so how can we fix it? Well, you can fix it while creating your image, for example using the Dockerfile directive such as "USER" while creating your image.
Since we are not creating the image here, what can we do? - We can mount /var/cache and /etc/nginx as volumes with write access and then pod will be created.
Give it a shot, try fixing it. If you need further help, LMK.
0 -
FWIW I got it to work using port 8080 (i.e. above 1024) and moving the pid file to one of my mounted volumes. I followed this example to build the nginx conf in a ConfigMap: https://gist.github.com/petitviolet/d36f33d145d0bbf4b54eb187b79d0244
0
Answers
-
@fazlur.khan ah yes the /var/cache I already found, but my problem was more that the nginx user was not allowed to open port 80
0 -
- Review the security-review1.yaml file to ensure that it meets security standards and best practices
- Analyze the security-review1.yaml file to identify any potential security issues.
- Examine the security-review1.yaml file for any potential security threats or weaknesses
4.Check the security-review1.yaml file for any potential security flaws or weaknesses. - Scan the security-review1.yaml file for any potential security risks or vulnerabilities.
0 -
Here's what I'm trying:
- set
spec.containers[0].securityContext.runAsUser
to be 101, the same as the nginx user in the container image (although I don't like this solution, I'd prefer a solution where root in the container maps to a unique UID on the host) - using an emptyDir volume for /var/lib/nginx (it wants to create proxy_temp, client_temp, and more)
- set
spec.containers[0].securityContext.capabilities.add[0]."NET_BIND_SERVICE"
... but that doesn't appear to be effective as the container still gets a permission denied when binding to 0.0.0.0:80
So I went to diagnose what was happening. A altered my Deployment to create the pod with command as ["/usr/bin/sleep", "inf"]... this means it won't start nginx but will just cause the a container to start, which I can then exec into to inspect the environment:
nginx@securityreview:/$ grep ^Cap /proc/1/status CapInh: 0000000000000000 CapPrm: 0000000000000000 CapEff: 0000000000000000 CapBnd: 00000000a80425fb CapAmb: 0000000000000000
Well that's kinda interesting, because the CapPrm ('Permitted', or maximum) capabilities is empty, so something must be removing capabilities.
Compare this with another what we did earlier:
cameron_kerr_nz@a-cp:~/review6$ k exec secondapp -c busy -- grep ^Cap /proc/1/status CapInh: 0000000000000000 CapPrm: 0000000000000000 CapEff: 0000000000000000 CapBnd: 00000000aa0435fb CapAmb: 0000000000000000 cameron_kerr_nz@a-cp:~/review6$ k exec secondapp -c webserver -- grep ^Cap /proc/1/status CapInh: 0000000000000000 CapPrm: 00000000a80425fb CapEff: 00000000a80425fb CapBnd: 00000000a80425fb CapAmb: 0000000000000000
And here's the configuration from that:
containers: - name: webserver image: nginx - name: busy image: busybox command: - sleep - "3600" securityContext: runAsUser: 2000 allowPrivilegeEscalation: false capabilities: add: ["NET_ADMIN", "SYS_TIME"]
Comparing with the review exercise, it would appear that when securityContext.capabilities.add has been set, we're seeing that CapEff (the 'Effective' set) is not as expected.
It is very useful to realise that this is because of the behaviour of Linux Capabilities when transitioning from UID 0 to UID !0. There's a long-standing bug about this:
- https://github.com/kubernetes/kubernetes/issues/56374
- workaround using sysctls instead to set the range of priviledged ports: https://github.com/kubernetes/kubernetes/issues/56374#issuecomment-928917495
- the other fix for this (lacking ambient capabilities) is to set NET_BIND_SERVICE capability on the executable instead (ie. on nginx). --- I tried this, it wasn't enough
- https://github.com/kubernetes/enhancements/issues/2763 <-- the enhancement that made it as an Alpha in 1.24 (but ended up being a CVE?).
I would say that it should be required to read about this issue, because you're very likely to bump into it; and your experience is likely to be quite unpleasant.
What I ended up doing that did work:
- Use
runAsUser: 101
in the containersecurityContext
- Don't use any
capabilities
- Instead, use the
sysctls
in the Pod'ssecurityContext
(not the container's, but the pod's) - Provide a custom nginx.conf that doesn't specify
user
and sets the various paths (as per the documentation in the section 'Running Nginx as a non-root user' at https://hub.docker.com/_/nginx)
While you're reading about these issues, I found it useful to compare with what OpenShift does; all pods will run as a non-privileged dynamic UID, but with GID 0. So anything that should be writable by the container should have group-write permission. An interesting way of doing it, although one that many container images aren't written to expect. I suspect there will be container runtimes that can use 'rootless' containers, where the UID running 'within' the container may be 0; but that is mapped to a non-root UID outside of the container. (podman does this already; presumably CRI-O could as well; I haven't looked).
0 - set
Categories
- All Categories
- 50 LFX Mentorship
- 103 LFX Mentorship: Linux Kernel
- 575 Linux Foundation IT Professional Programs
- 304 Cloud Engineer IT Professional Program
- 125 Advanced Cloud Engineer IT Professional Program
- 53 DevOps Engineer IT Professional Program
- 60 Cloud Native Developer IT Professional Program
- 5 Express Training Courses
- 5 Express Courses - Discussion Forum
- 2K Training Courses
- 19 LFC110 Class Forum
- 7 LFC131 Class Forum
- 27 LFD102 Class Forum
- 157 LFD103 Class Forum
- 20 LFD121 Class Forum
- 1 LFD137 Class Forum
- 61 LFD201 Class Forum
- 1 LFD210 Class Forum
- LFD210-CN Class Forum
- 1 LFD213 Class Forum - Discontinued
- 128 LFD232 Class Forum
- LFD237 Class Forum
- 23 LFD254 Class Forum
- 611 LFD259 Class Forum
- 105 LFD272 Class Forum
- 1 LFD272-JP クラス フォーラム
- 1 LFD273 Class Forum
- 2 LFS145 Class Forum
- 24 LFS200 Class Forum
- 739 LFS201 Class Forum
- 1 LFS201-JP クラス フォーラム
- 10 LFS203 Class Forum
- 75 LFS207 Class Forum
- 300 LFS211 Class Forum
- 54 LFS216 Class Forum
- 47 LFS241 Class Forum
- 41 LFS242 Class Forum
- 37 LFS243 Class Forum
- 11 LFS244 Class Forum
- 35 LFS250 Class Forum
- 1 LFS250-JP クラス フォーラム
- LFS251 Class Forum
- 140 LFS253 Class Forum
- LFS254 Class Forum
- 1.1K LFS258 Class Forum
- 10 LFS258-JP クラス フォーラム
- 93 LFS260 Class Forum
- 132 LFS261 Class Forum
- 33 LFS262 Class Forum
- 80 LFS263 Class Forum
- 15 LFS264 Class Forum
- 11 LFS266 Class Forum
- 18 LFS267 Class Forum
- 17 LFS268 Class Forum
- 23 LFS269 Class Forum
- 203 LFS272 Class Forum
- 1 LFS272-JP クラス フォーラム
- LFS274 Class Forum
- LFS281 Class Forum
- 233 LFW211 Class Forum
- 172 LFW212 Class Forum
- 7 SKF100 Class Forum
- SKF200 Class Forum
- 902 Hardware
- 219 Drivers
- 74 I/O Devices
- 44 Monitors
- 115 Multimedia
- 209 Networking
- 101 Printers & Scanners
- 85 Storage
- 763 Linux Distributions
- 88 Debian
- 66 Fedora
- 15 Linux Mint
- 13 Mageia
- 24 openSUSE
- 142 Red Hat Enterprise
- 33 Slackware
- 13 SUSE Enterprise
- 357 Ubuntu
- 479 Linux System Administration
- 41 Cloud Computing
- 70 Command Line/Scripting
- Github systems admin projects
- 95 Linux Security
- 78 Network Management
- 108 System Management
- 49 Web Management
- 68 Mobile Computing
- 23 Android
- 30 Development
- 1.2K New to Linux
- 1.1K Getting Started with Linux
- 537 Off Topic
- 131 Introductions
- 217 Small Talk
- 21 Study Material
- 826 Programming and Development
- 278 Kernel Development
- 514 Software Development
- 928 Software
- 260 Applications
- 184 Command Line
- 3 Compiling/Installing
- 76 Games
- 316 Installation
- 62 All In Program
- 62 All In Forum
Upcoming Training
-
August 20, 2018
Kubernetes Administration (LFS458)
-
August 20, 2018
Linux System Administration (LFS301)
-
August 27, 2018
Open Source Virtualization (LFS462)
-
August 27, 2018
Linux Kernel Debugging and Security (LFD440)