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
- 206 LFX Mentorship
- 206 LFX Mentorship: Linux Kernel
- 733 Linux Foundation IT Professional Programs
- 339 Cloud Engineer IT Professional Program
- 165 Advanced Cloud Engineer IT Professional Program
- 66 DevOps Engineer IT Professional Program
- 132 Cloud Native Developer IT Professional Program
- 119 Express Training Courses
- 119 Express Courses - Discussion Forum
- 5.9K Training Courses
- 40 LFC110 Class Forum - Discontinued
- 66 LFC131 Class Forum
- 39 LFD102 Class Forum
- 219 LFD103 Class Forum
- 17 LFD110 Class Forum
- 32 LFD121 Class Forum
- 17 LFD133 Class Forum
- 6 LFD134 Class Forum
- 17 LFD137 Class Forum
- 70 LFD201 Class Forum
- 3 LFD210 Class Forum
- 2 LFD210-CN Class Forum
- 2 LFD213 Class Forum - Discontinued
- 128 LFD232 Class Forum - Discontinued
- 1 LFD233 Class Forum
- 2 LFD237 Class Forum
- 23 LFD254 Class Forum
- 684 LFD259 Class Forum
- 109 LFD272 Class Forum
- 3 LFD272-JP クラス フォーラム
- 10 LFD273 Class Forum
- 95 LFS101 Class Forum
- LFS111 Class Forum
- 2 LFS112 Class Forum
- 1 LFS116 Class Forum
- 3 LFS118 Class Forum
- 2 LFS142 Class Forum
- 3 LFS144 Class Forum
- 3 LFS145 Class Forum
- 1 LFS146 Class Forum
- 2 LFS147 Class Forum
- 8 LFS151 Class Forum
- 1 LFS157 Class Forum
- 10 LFS158 Class Forum
- 4 LFS162 Class Forum
- 1 LFS166 Class Forum
- 3 LFS167 Class Forum
- 1 LFS170 Class Forum
- 1 LFS171 Class Forum
- 2 LFS178 Class Forum
- 2 LFS180 Class Forum
- 1 LFS182 Class Forum
- 4 LFS183 Class Forum
- 30 LFS200 Class Forum
- 737 LFS201 Class Forum - Discontinued
- 2 LFS201-JP クラス フォーラム
- 17 LFS203 Class Forum
- 112 LFS207 Class Forum
- 1 LFS207-DE-Klassenforum
- LFS207-JP クラス フォーラム
- 301 LFS211 Class Forum
- 55 LFS216 Class Forum
- 49 LFS241 Class Forum
- 43 LFS242 Class Forum
- 37 LFS243 Class Forum
- 13 LFS244 Class Forum
- 1 LFS245 Class Forum
- 45 LFS250 Class Forum
- 1 LFS250-JP クラス フォーラム
- LFS251 Class Forum
- 143 LFS253 Class Forum
- LFS254 Class Forum
- LFS255 Class Forum
- 6 LFS256 Class Forum
- LFS257 Class Forum
- 1.2K LFS258 Class Forum
- 9 LFS258-JP クラス フォーラム
- 114 LFS260 Class Forum
- 152 LFS261 Class Forum
- 41 LFS262 Class Forum
- 82 LFS263 Class Forum - Discontinued
- 15 LFS264 Class Forum - Discontinued
- 11 LFS266 Class Forum - Discontinued
- 23 LFS267 Class Forum
- 18 LFS268 Class Forum
- 29 LFS269 Class Forum
- 199 LFS272 Class Forum
- 1 LFS272-JP クラス フォーラム
- LFS274 Class Forum
- 3 LFS281 Class Forum
- 2 LFW111 Class Forum
- 257 LFW211 Class Forum
- 176 LFW212 Class Forum
- 12 SKF100 Class Forum
- SKF200 Class Forum
- 791 Hardware
- 199 Drivers
- 68 I/O Devices
- 37 Monitors
- 98 Multimedia
- 174 Networking
- 91 Printers & Scanners
- 85 Storage
- 754 Linux Distributions
- 82 Debian
- 67 Fedora
- 16 Linux Mint
- 13 Mageia
- 23 openSUSE
- 147 Red Hat Enterprise
- 31 Slackware
- 13 SUSE Enterprise
- 351 Ubuntu
- 464 Linux System Administration
- 39 Cloud Computing
- 70 Command Line/Scripting
- Github systems admin projects
- 91 Linux Security
- 78 Network Management
- 101 System Management
- 47 Web Management
- 56 Mobile Computing
- 17 Android
- 28 Development
- 1.2K New to Linux
- 1K Getting Started with Linux
- 365 Off Topic
- 113 Introductions
- 171 Small Talk
- 20 Study Material
- 522 Programming and Development
- 291 Kernel Development
- 213 Software Development
- 1.1K Software
- 212 Applications
- 180 Command Line
- 3 Compiling/Installing
- 405 Games
- 311 Installation
- 79 All In Program
- 79 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)