![\"\"](\"http:\/\/cdn.rancher.com\/wp-content\/uploads\/2017\/02\/16180354\/Training.png\")
<\/a>\nEnjoying this article? Check out all of our learning resources at
\nrancher.com\/learn<\/a><\/p>\n
Securing the Stack<\/h3>\n
There are two main considerations to bear in mind when securing your Securing your orchestrator requires more work than simply turning on If you use Kubernetes, you may also find this article on security best The infrastructure you use to host your container environment could be When it comes to containers and storage, however, one important point to Running SELinux or AppArmor on the container host can help to defend the You should secure the code running inside your containers just as you Keeping a container environment secure is a big task because there are
\nimage registry. First, you need to make sure to lock down access
\ncontrol. Your approach to doing this will vary depending on which
\nregistry you use. Some registries offer finer-tuned access control
\nfeatures than others, but all of the mainstream registries provide some
\nsecurity controls. (For an overview of different registry options,
\nincluding a comparison of the security features built into them, check
\nout Container Registries You May Have
\nMissed<\/a>) The
\nsecond challenge is detecting security vulnerabilities inside container
\nimages themselves. For this task, two tools are available: Clair from
\nCoreOS and Docker Security Scanning from Docker. Both of these image
\nscanners will check an image for known malware signatures. They\u2019re
\ndesigned mainly to be integrated into CoreOS\u2019s and Docker\u2019s registries,
\nbut they can also work in standalones mode by manually scanning an
\nimage.<\/p>\nOrchestrator<\/h3>\n
\nsome access control features or running a scanner. Orchestrators are
\ncomplex tools, and their inner workings vary from one orchestrator to
\nanother. Explaining all of the details of configuring an orchestrator
\nfor maximum security is beyond the scope of this article. In general,
\nhowever, key principles to follow include:<\/p>\n\n
\nBe wary of third-party package repositories.<\/li>\n
\npublic-facing network connections to the minimum necessary to run
\nyour application.<\/li>\n
\navailability in order to mitigate the impact of potential DDoS or
\nsimilar attacks.<\/li>\n<\/ul>\n
\npractices<\/a>
\nto be helpful. A similar guide for Mesos is available
\nhere<\/a>.<\/p>\nHosting Infrastructure<\/h3>\n
\non-premises, in the cloud, or in some cases, a mix of both. Whatever it
\nlooks like, you should be sure to secure the infrastructure as much as
\npossible. If you manage your host servers yourself, make sure they are
\nlocked down with kernel hardening tools like SELinux or AppArmor. For
\ncloud-based deployments, take advantage of access control features (such
\nas IAM roles on AWS) to configure access to your environment. Security
\nauditing and monitoring tools will help to keep your infrastructure
\nsecure, too.<\/p>\nStorage<\/h3>\n
\nkeep in mind is that, in many cases, many containers might share access
\nto the same storage directories. This happens if you map directories
\ninside containers to a shared location on the host. Under these
\nconditions, it\u2019s especially important to make sure that any container
\nwith access to a shared storage location is secure. You should also
\nlimit storage access to read-only in cases where a container does not
\nneed write permissions. And it\u2019s always a good idea to have rollback
\nfeatures built into your storage system so that you can undo changes to
\ndata if necessary.<\/p>\nContainer Daemon<\/h3>\n
\nDocker daemon against attack, but that is only one security challenge to
\nkeep in mind when it comes to the daemon. You should also make sure that
\ndaemon socket connections are securely authenticated and
\nencrypted<\/a>. Of course,
\nit\u2019s also essential to keep your Docker installation up-to-date to avoid
\nsecurity vulnerabilities in the daemon.<\/p>\nApplication Code<\/h3>\n
\nwould secure any type of application code\u2014by obtaining the code from a
\ntrusted source and auditing it with security tools designed to catch
\nvulnerabilities. Clair and Docker Security Scanning can help with the
\nlatter, but they are not designed to be all-purpose static application
\nsecurity testing solutions. For that reason, you may benefit from
\ndeploying a tool like Veracode or OWASP to scan your code for
\nvulnerabilities.<\/p>\nConclusion<\/h3>\n
\nso many moving parts. The details of your security strategy will vary
\ndepending on exactly which types of registries, orchestrators, hosting
\ninfrastructure and so on that you choose to include in your stack. But
\nwhatever your environment looks like, the key to keeping it secure is to
\nremember that there is no one-stop shopping. You have to keep all of the
\ndifferent layers in mind, and develop a security plan that addresses
\neach one. Chris Riley (@HoardingInfo) is a technologist who has
\nspent 12 years helping organizations transition from traditional
\ndevelopment practices to a modern set of culture, processes and tooling.
\nIn addition to being a research analyst, he is an O\u2019Reilly author,
\nregular speaker, and subject matter expert in the areas of DevOps
\nstrategy and culture. Chris believes the biggest challenges faced in the
\ntech market are not tools, but rather people and planning.<\/em><\/p>\n