Skip to content

Background

A simple Kubernetes deployment consists of a cluster that contains nodes, which run the containers, as well as a control plane that can be used to manage those nodes. The control plane is also referred to as the "Kubernetes API Server". KubeCTL is the Kubernetes command-line tool that developers and operations personnel use to interact with the Kubernetes API server.

In most environments, users are required to:

  • Connect to a VPN that allows them to run commands against that API server by addressing it over the same local network, OR
  • Securely connect to a Bastion in the same VPC that allows them to access the API Server

Background

Zero Trust security is a modern, security model that requires strict identity verification for every user and device trying to access resources on a private network immaterial of their location (i.e. inside/outside of the network perimeter).

Traditional IT network security is based on a castle-and-moat concept where users inside the castle are trusted by default. The fundamental issue with this approach is that once the attacker gains access to the network, they have access to everything inside.

Just because a user has access to a VPN/Bastion should not mean that the user has unfettered access to everything.

Requirements

In a typical operational deployment, the needs of developers, operations personnel as well as security/governance personnel need to be addressed.

Developers and Operations

  • Want seamless access to a fleet of clusters from anywhere
  • Want the convenience of both Browser and KubeCTL CLI based multi-cluster access
  • Want a great user experience and be productive. for e.g. auto completion of KubeCTL commands
  • Want to be productive i.e. immediate access transparently driven by user’s group membership in the corporate identity directory
  • Want to avoid the operational complexity and latency/performance issues with SSH, Bastion or VPNs

Security and Governance

  • Want the Kubernetes API Server to be cloaked and completely private
  • Want to standardize on a modern zero-trust access model
  • Do not want to punch holes in firewalls for kube api server access from users spread around world (i.e. no predictable IP or VPN solution)
  • Want the ability to instantly revoke user access
  • Want to eliminate orphaned or dangling k8s roles on clusters
  • Want strict enforcement of separation of duties across functions
  • Want strong authentication (TOTP, U2F etc.) integrated with Corporate Identity Provider via SSO
  • Want authorization driven by group membership via integration with Corporate Identity Provider (IdP)
  • Want to enforce read only access for certain users– k8s verbs like “get”, ”describe”, “logs”
  • Want centralized audit trail of all KubeCTL activity
  • Want to decommission expensive, legacy VPNs and unnecessary bastions deployed globally