3 ms·
Where does the post tell you to do that? If anything it tells you a) spend a lot of time paying attention to what sounds like what you might call "the general s
by lvh 8y ago
Where does the post tell you to do that? If anything it tells you a) spend a lot of time paying attention to what sounds like what you might call "the general security implications of containers" and b) it also tells you that systems like K8s mean that you may not need to run said container to your prod database.
Saying that one of the senior engineers at Gravitational "is unaware of the general security implications of containers" is a pretty bold claim.
- verdverm 8y agoUnder alternatives, Containers and Schedulers, 3rd section from the end
- old-gregg 8y agoI think he's saying "stop trying to getting shell on your production hosts and use APIs provided by container orchestrators like Kubernetes". Which makes perfect sense because those APIs have a proper, granular security model with RBAC, etc.
- lvh 8y agoThere's no "Containers and orchestration" section, but there's a "Containers and Schedulers" which is what I assume you meant. Here's the full text of that section: ---- Once you have a containerized application, you can use a container scheduler like Kubernetes or Docker Swarm to run it on your production hosts. Container schedulers provide a well defined API to access the status of the container like its state and logs. This means users only have access to the running programs over a well defined API. Because containers are self-contained images with everything they need to run, developers do not need access to production hosts to debug issues. For example, a good workflow allows developers to spin up a cluster locally on dummy data they control. However within production they would only have access to logs. This way data exfiltration is prevented because direct access to data is simply not allowed. ---- I read that as saying "no, don't run random containers to attach to prod, instead rely on orchestration to get you logs and instrumentation". Or is the entirety of your argument "containers are bad because images are full of vulns"?
- verdverm 8y agoI'm not saying containers are bad, I use them everywhere. They require the same audit and lockdown that the host system needs. If the container accesses data, and the container has vulns, then we still have to deal with situation 1, malicious actors. From the article: > Another form of system hardening you can use is containers.