I 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.

There'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"?

I'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.