Skip to content

Secure Config

Overview

Icon Meaning
❌ Not Recommended
🗒️ Rationale
✅ Recommendation
⚠️ Warning

Components

Component Description
API Server REST API for controlling Kubernetes:
  • A user who has full permissions on this API has the equivalent of root access on every machine in the cluster
  • All components (e.g., kubelet running on a node or users issuing kubectl commands) need to communicate with the API server
  • kubectl is a client for this API
Insecure Port:
  • ❌ By default, the API server listen on the insecure port 8080
    • Any requests to this port bypass authentication and authorization checks
    • If you leave this port open, anyone who gains access to the host your master is running on has full control over your entire cluster
  • ✅ Disable the insecure port
    • kube-apiserver ... --insecure-port=0
    • ensure --insecure-bind-address is not set
    • With the insecure port closed, the API can be accessed only over a secure, encrypted TLS connection via the secure port
  • 🗒️ Check whether the insecure port is open on the default port: if you get a response by requesting to 8080, then it is open
    • $ curl <API-SERVER IP>:8080
      { "paths": [
      "/api",
      "/api/v1",
      "/apis", ...
    • $ curl <API-SERVER IP>:8080
      Connection Refused
Kubelet Agent running on each node:
  • Responsible for interacting with the container runtime to launch pods, and report node and pod status and metrics
  • Each kubelet also operates an API, through which other components ask it to do things like starting and stopping pods
  • If unauthorized users can access this API (on any node) to execute code on the cluster, it’s possible to gain control of the entire cluster
  • kube-apiserver is a client through which commands can be executed on specific nodes
Minimize the Attack Surface
  • ✅ Disable anonymous access
    • --anonymous-auth=false
    • unauthenticated requests will receive Unauthorized Access error responses
    • this requires the API server to identify itself to the kubelet
      • --kubelet-client-certificate
      • --kubelet-client-key
  • ✅ Ensure that requests are authorized
    • --authorization-mode=Webhook (everything but AlwaysAllow)
  • ✅ Limit the permissions of kubelets
    • include NodeRestriction in the --admission-control settings
    • this restricts a kubelet so that it can modify only pods that are bound to it and its own Node object
  • ✅ Turn off the read-only port
    • --read-only-port=0
    • this port allows an anonymous user to access information about running workloads
    • while access to this port doesn't allow to control the cluster, exposing information about what's running could make it easier to attack
  • 🗒️ Check what access is available
    • $ curl -sk https://<IP>:10250/pods/
    • If --anonymous-auth is false == 401 Unauthorized
    • If --anonymous-auth is true and --authorization-mode is Webhook == 403 Forbidden (user=system:anonymous, verb=get, resource=nodes, subresource=proxy)
    • If --anonymous-auth is true and --authorization-mode is AlwaysAllow == list of pods
etcd Distributed key-value store:
  • Used to store configuration and state information
  • Anyone who can write to etcd can effectively control your Kubernetes cluster
Ensure that only authenticated access is permitted:
  • ✅ Enable HTTPS connections to etcd
    • --cert-file
    • --key-file
  • ✅ Ensure that access to etcd requires authentication
    • --client-cert-auth=true
    • --trusted-ca-file (to specify the certificate authority that has signed the client certificates)
  • ✅ Disallow the generation and use of self-signed certificates
    • --auto-tls=false
  • ✅ Require etcd nodes to communicate with each other securely
    • --peer-client-cert-auth=true
    • --peer-auto-tls=false
    • also specify --peer-cert-file, --peer-key-file and --peer-trusted-ca-file
  • ✅ Certificate authority that signed etcd's certificate
    • --etcd-cafile (on the API server)
  • ✅ Allow the API server to identify itself to etcd
    • --etcd-certfile
    • --etcd-keyfile
Dashboard Access from a local machine:
  • $ kubectl proxy
Hardening
  • ✅ Allow only authenticated access
  • ✅ Use RBAC
    • Limit the privileges that users have so they can administer only the resources they need to
  • ✅ Make sure the Dashboard service account has limited access
    • After reaching the Dashboard login screen, users have the option to Skip
    • This means that rather than authenticating as their own user identity, they access the Dashboard with the Dashboard's service account
  • ✅ Don't expose the Dashboard to the public internet