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 sect

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