1,338 karma · joined January 2, 2014
In our case, we have our own base container images that include this user. The base images are either just plain copies of official ones (such as dotnet or curl) or also includes stuff that almost everyone needs (such as MSSQL ODBC drivers, libxml2, curl etc) in the case of python/R/node.
In your Dockerfile, add a non-root user with UID and GID 1000, then in the end of your Dockerfile, right before a CMD or ENTRYPOINT you change to that user.
In your kubernetes yaml manifest, you can now set runAsNonRoot to true and runAsUser & runAsGroup to 1000.
Then there’s the privileged and allowPrivilegeEscalation fields, these can nearly always be set to false unless you actually need the extra privileges (such as using a GPU) on a shared node.
Then there’s seccomp profiles and the system capabilities. If you can run your container as the non-root user you’ve created, and you don’t need the extra privileges then these can safely also be set to the most restricted. Non-privileged non-root is the same as all capabilities are dropped.
The tricky one is the readOnlyRootfilesystem field. This includes /tmp, which is considered a global writeable directory, so the workaround is to make a in-memory volume and mount it at /tmp to make it writable. Likewise, your $HOME/.cache and $HOME/.local directories (for the user you created in your Dockerfile) are usually used by third party packages, so creating mounts here can be useful as well (if for some reason you can’t point it to /tmp instead).
[1] https://kubernetes.io/docs/tasks/configure-pod-container/sec...
I will admit though, that Debian-slim still has some non-essential stuff that usually isn’t needed at runtime, a shell is still neat for debugging or local development. This trade off could be considered a security risk, but it’s rather simple to restrict other stuff at runtime (such as run as non-privileged, non-root user with all capabilities dropped and a read-only file system except for /tmp).
It’s a balancing act between ease-of-use and security. I don’t think I’d get popular with the developers by forcing them to use “FROM scratch” and let them figure out exactly what their application needs at runtime and what stuff to copy over from a previous build stage.
We’re using Trivy but have also been evaluating Snyk and Grype. All these can do container image scan, but these are, in my opinion, nearly useless, as the vulnerability exists in the base image I don’t control. Apart from using a newer base image (maybe based on a newer version of Ubuntu/Debian/Alpine) there’s little to do.
Scanning for language-specific vulnerabilities in third party packages is useful, as that’s something we can control and the fix is usually to update some python or node package (but this is also something dependabot can also help with, albeit in a different manner).
Hosted on gitlab pages (for now), built with the Hugo SSG.
Mostly showcasing some small side projects as well as my ceramics. I’m considering opening a small web shop as well.
Simple and privacy focused. I pay 3 euro/month for 10 GB email storage and 25 email aliases which are very nice. I haven't had a problem with them so far since 2015.
For context, it is a medium-sized (~40 devs) commodities trading company running some hundred applications in azure k8s but considering moving to on-prem k8s.
I want to use the old pi as a node in a k3s (lightweight kubernetes distro) cluster but the current releases won’t run. I’m currently reading up on qemu and the k3s build process (which to me seems kinda convoluted).
Could you take a quick look at mealie and make a comparison between the two?
I have always found this to make extremely good sense, but I see quite few doing it besides me.
An average of 8% a year with lower risk[1] than stocks is quite attractive, but I cannot help but think that wine should be paired with a nice meal and shared with friends instead of traded/invested. However, when investing in wine, nothing stops me from drinking my investment!
It’s “just” a client issue, and OpenEthereum is “only” used by ~11% of the nodes. I believe the former name is Parity, which had a major bug related to frozen coins some years ago.
See https://mobile.twitter.com/etherscan/status/1382662485832994...
I think I've read it 4 times the last 7 years, which may not be that often, but it definitely has a special place in my heart.
I've thought about it, but don't think it's possible. Basically quantum chemical methods like Hartree-Fock or Coupled Cluster is a question of finding eigenvalues to some very very large matrices and/or solving non-linear equation. Verifying a solution (such as electron correlation energy) can, to my knowledge, only be done by using the result and checking if the equations are still valid, which pretty much is just doing the whole work.
We are still a long way from modelling protein folding in solution with 100% quantum mechanics. Luckily, classical molecular dynamics are quite good at modelling biochemical systems (to a degree). There are a ton of errors that a much bigger than quantum (and relativistic) effects anyway.