When Docker Enterprise added support for Windows containers running on Swarm with the release of Windows Server 2016, we had to tackle challenges that are less pervasive in pure Linux environments. Chief among these was Active Directory authentication for container-based services using Group Managed Service Accounts, or gMSAs. With nearly 3 years of experience deploying and running Windows container applications in production, Docker has solved for a number of complexities that come with managing gMSAs in a container-based world. We are pleased to have contributed that work to upstream Kubernetes.
Challenges with gMSA in Containerized Environments
Aside from being used for authentication across multiple instances, gMSAs solves for two additional problems:
Containers cannot join the domain, and;When you start a container, you never really know which host in your cluster it’s going to run on. You might have three replicas running across hosts A, B, and C today and then tomorrow you have four replicas running across hosts Q, R, S, and T.
One way to solve for this transience is to place the gMSA credential specifications for your service on each and every host where the containers for that service might run, and then repeat that for every Windows service you run in containers. It only takes a few combinations of servers and services to realize this solution just doesn’t scale. You could also place the credential specs inside the image itself, but then you have issues with flexibility if you later change the credspec the service uses.
Figure 1: Managing the matrix of container, credspecs, and hosts doesn’t scale
With Docker Enterprise 3.0 we created a new way to manage gMSA credspecs in Swarm environments. Rather than manually creating and copying credspecs to every potential host, you can instead create a service configuration:
docker config create credspec…
which is a cluster-wide resource and can be used as a parameter when you create a Windows container service:
docker service create –credential-spec=”config://credspec”…
Swarm then automatically provides the credential spec to the appropriate container at runtime. Much like a secret, the config is only provided to containers that require it; and unlike a typical docker config, the cred spec is not mounted as a file in the system.
Figure 2: Swarm and Kubernetes orchestrators provide gMSA credspecs only when & where needed
Bringing gMSA credspecs to Kubernetes
Now that Kubernetes 1.14 has added support for Windows, the number of Windows container applications is likely to increase substantially and this same gMSA support will be important to anybody trying to run production Windows apps in their Kubernetes environment. The Docker team has been supporting this effort within the Kubernetes project with help from the SIG-Windows community. gMSA support is in the Alpha release phase in Kubernetes 1.14.
gMSAs in Kubernetes work in a similar fashion to the config in Swarm: you create a credspec for the gMSA, use Kubernetes RBAC to control which pods can access the credspec, and then your pods can access the appropriate gMSA as needed. Again, this is still in Alpha right now so if you want to try it out you will have to enable the feature first.
We have additional work we are contributing upstream in addition to the gMSA work, like CSI support for Windows workloads, and we’ll share more about that in the weeks ahead as they reach alpha release stages.
Learn more about #Docker’s contribution to authentication for Windows containers in @kubernetesioClick To Tweet
Call to Action
If you’re attending OSCON check out the “Deploying Windows apps with Draft, Helm, and Kubernetes” session by Jessica Deen Test out the new gMSA config specs, coming soon in Docker Enterprise 3.0Review and contribute to the Kubernetes Windows gMSA SIG or other enhancement proposalsLearn more about Microsoft Group Managed Service Accounts
The post Docker’s Contribution to Authentication for Windows Containers in Kubernetes appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/
Published by