Controlling user access to Kubernetes is important in any production environment. Fortunately, Kubernetes has a robust RBAC subsystem that integrates with existing IAM providers, such as Active Directory and other LDAP systems.

Most organizations already have a centralized IAM provider, such as Active Directory, that is integrated with company HR systems to simplify employee lifecycle management.

Fortunately, Kubernetes leverages existing IAM providers instead of implementing its own. For example, a new employee joining the company will automatically get an identity in Active Directory, which integrates with Kubernetes RBAC to automatically grant that user certain access to Kubernetes. Likewise, an employee leaving the company will automatically have his or her Active Directory identity removed or disabled, resulting in their access to Kubernetes being revoked.

RBAC went GA in Kubernetes 1.8, and it is highly recommended that you leverage its full capabilities.

Managing Remote SSH access to cluster nodes

Almost all Kubernetes administration is done via the API server, meaning it should be rare for a user to require remote SSH access to Kubernetes cluster nodes. In fact, remote SSH access to cluster nodes should only be required in the following instances:

• Performing node management activities that cannot be performed via the Kubernetes API.
• Break the Glass activities, such as when the API server is down.
• Deep troubleshooting.

You should probably have tighter controls over who has remote access to the control plane nodes.