Continuing the discussion from Use Cases for Windows in Kubernetes
I believe that securing containers is a workload-specific activity. In general, you should follow the same principles for Windows as for Linux containers, and then address the attack surface of your application. We are exploring the possibility of providing some more prescriptive guidance and we’d love to know what you’re most concerned about.
Note that Windows containers have some significant differences from Linux containers which do affect both the risks and mitigations associated with securing them. We’d love feedback on the documentation in this regard.
Thanks for all the hard work on this 
, really appreciate it.
I think right now my concerns are more related to how best to manage windows containers especially in a hybrid cluster, and what tools we can leverage to assist in Enforcing policy. The document you have now is a really good place to start. I’ll be giving it another read tonight.
Wanted to followup before I got to carried away with work. I ran things by our security team to see what if any concerns they had. The biggest thing that stood out for them was that Secrets are stored in plain text.
I don’t think that will be a big issue for us down the road as we are currently in the process of adopting CyberArk and will be using conjur for Secret management.
I will check back in if we come up against any other concerns as we start exploring Windows Containers more.
Secrets are a sticky subject. I think you’re headed down the right path. Kubernetes secrets are encoded in base64 which is not encryption. Linux allows you to store them in memory which reduces but does not eliminate the risk of exposure. Windows stores secrets on disk, and the documentation recommends that you protect them with ACL and use file-level encryption with BitLocker. If you want more control of access to, and audit of, secrets then using an external service like Hashicorp Vault, CyberArk, or services from the cloud vendors seems the best route.