search

BLOG02d: KUBECONFIG Detailed Breakdown

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://172.31.66.87:6443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    user: kubernetes-admin
  name: kubernetes-admin@kubernetes
current-context: kubernetes-admin@kubernetes
kind: Config
preferences: {}
users:
- name: kubernetes-admin
  user:
    client-certificate-data: DATA+OMITTED
    client-key-data: DATA+OMITTED

This document breaks down the kubeconfig file into 5 sections:

1. apiVersion: v1

This field indicates that the kubeconfig structure conforms to the Kubernetes v1 API specification.

All kubeconfig files use this API version.

2. clusters:

This section describes how to reach the Kubernetes API server.

Example entry:

hashtag
name: kubernetes

The cluster name within the kubeconfig file. This name does not need to match the actual cluster name; it is a logical identifier used within the kubeconfig file.

hashtag
server: https://172.31.66.87:6443

This specifies the Kubernetes API Server endpoint.

  • IP address: 172.31.66.87

  • Port: 6443 (default API server port)

All kubectl commands are directed to this server.

hashtag
certificate-authority-data: DATA+OMITTED

This field contains the CA certificate (base64 encoded). It ensures:

  • The client can trust the Kubernetes API server

  • Protection against man-in-the-middle attacks

  • TLS verification

The equivalent file is typically located at:

This CA signs:

  • apiserver.crt

  • kubelet client certs

  • admin certificates

3. users:

This section describes how the client (kubectl, Lens, scripts) authenticates to the cluster.

Example entry:

hashtag
name: kubernetes-admin

This is the local name of the user in the kubeconfig file.

This name is not sent to Kubernetes; it serves as a local identifier.

hashtag
client-certificate-data

This field contains the user certificate (base64 encoded). The certificate contains the following identity information:

The O=system:masters field indicates: This user is a cluster super-admin with full access privileges.

hashtag
client-key-data

This field contains the private key for the above certificate.

Together, the certificate and key establish the user identity.

This enables kubectl to authenticate cryptographically with the API server.

4. contexts:

A context binds together:

Example entry:

hashtag
cluster: kubernetes

References the cluster defined earlier under clusters:.

hashtag
user: kubernetes-admin

References the user defined under users:.

hashtag
name: kubernetes-admin@kubernetes

This is the context name used when switching contexts:

5. current-context

This field defines which context is currently active:

This configuration means:

  • Use the kubernetes cluster

  • Use the kubernetes-admin user

  • Apply all permissions granted to this user

This is the context that kubectl uses by default unless overridden.

Putting It All Together: How kubectl Authenticates

When executing:

kubectl performs the following steps:

  1. Reads current-context → identifies kubernetes-admin@kubernetes

  2. Context references:

    • cluster: kubernetes

    • user: kubernetes-admin

  3. Cluster configuration specifies:

  4. User configuration specifies:

    • Present admin certificate and key for authentication

  5. API server validates:

    • Verifies that the certificate is signed by the cluster CA

  6. Upon successful validation, the user identity is established as:

  1. Members of system:masters have unrestricted admin access.

This explains why:

works without any RBAC configuration.

Meaning of These Internal Certificate Identities

When decoding the certificate:

The output will show:

hashtag
CN=kubernetes-admin

This is the actual username recognized by Kubernetes (visible via kubectl auth whoami).

hashtag
O=system:masters

This is the admin group that automatically grants full cluster privileges.

The group system:masters maps to:

Why Is This Important?

This configuration defines:

  • How Kubernetes identifies user identity

  • How kubectl communicates with the API server securely

  • How admin privileges are obtained

  • How tools such as Lens, kubectl, and Terraform connect to the cluster

Understanding this configuration is essential for managing:

  • Authentication

  • RBAC

  • Multi-user setups

  • Secure admin access

  • Third-party integrations

PreviousBLOG02c: Understanding Kubernetes Cluster Files, Users, Certificates & AuthenticationNextLAB02b: Deep Dive into Kubeconfig, Client Certificate & Server Certificate

Last updated