191–200 of 203 posts
Earlier quoted context omitted.
For almost any serious job running in production, you might need CA certificates and openssl.
Unless you're behind a load balancer which terminates TLS and the traffic you deal with is purely http.
Earlier quoted context omitted.
Going through alpine:3.1 to alpine:3.9, then alpine:edge, I see that the following versions have the problem: 3.3, 3.4, 3.5, and 3.8.
3.8 looks fine? » docker run --rm -ti alpine:3.8 sh -c 'cat /etc/shadow | grep root' root:!::0::::: The others you mention though, I agree, they look less than fine. Also, has anyone reported this to the official Alpine repository? (since the Talos disclosure seems to be confused; it says official but has URLs to the Glider Labs version?) Edit: Ah, so here's the relevant GitHub issue for official Alpine Linux docker:…
Earlier quoted context omitted.
OK. In my experience it worked with any user account. I would install, create an account, and immediately use sudo to change the root password.
The first user account is considered an administrator account on most distros by default, so it has sudo privileges. If you can do what you said with a non-wheel/sudo account, that would be a serious vulnerability.
Earlier quoted context omitted.
For anyone who want a small image but with glibc, https://github.com/GoogleContainerTools/distroless is a good choice, especially if you are writing in static linked language e.g. Go and Rust.
"distroless" is just Debian packages. Their self-description is fairly annoyingly misleading, since they don't mention that they are just using packages from Debian.
Earlier quoted context omitted.
I trust myself who setup our infrastructure vs. the security guys who's automatic response to everything is deny all everywhere, encrypt everything everywhere (at rest encryption isn't enough, what can you do to get the db to work on the data encrypted internally 100% of the time?), and enable 2 factor on everything (the github gui has 2fa enabled, why aren't push/pull requests using 2fa?). I think may main point is…
Sounds like you need better security people.
I have always been a bit surprised at the popularity of Alpine Linux for docker images. It’s awesome that the images are pretty small, but a wide variety of software has been shown to run noticeably slower on Alpine compared to other distributions, in part due to its usage of musl instead of glibc. I’d think that a few megabytes of disk isn’t as valuable as the extra cpu cycles.
>"It’s awesome that the images are pretty small, but a wide variety of software has been shown to run noticeably slower on Alpine compared to other distributions, in part due to its usage of musl instead of glibc" Might you have any citation(s) for this? I have not heard this before. Could you elaborate on what some the "wide variety of software" is? Thanks.
Earlier quoted context omitted.
Adding a shell seems antithetical to deploying production code as a static-linked binary, not to mention an expansion of the attack surface of the container.
Without a shell, how does one debug if anything goes wrong?
Earlier quoted context omitted.
Which you probably shouldn't be doing for most of your services anyway.
I don't remember the last project I did which didn't have some sort of integration with an external service. I guess if you use microservices, most components won't need it; I mostly use monoliths.
Earlier quoted context omitted.
remote debugging is a shell
not necessarily. e.g. java runtimes can expose debugging ports when needed that operate on a custom protocol. or you can just build gdb into the container and run the process under gdb, then attach to the tty. or you can debug from the host system where the container's pid namespace is a descendant of the root namespace and the other namespaces can be accessed via /proc or unshare.