kubectl config view

When to Use kubectl config view

kubectl config view displays the merged kubeconfig that kubectl uses to connect to clusters. It is the primary tool for inspecting and debugging your Kubernetes client configuration, including clusters, users, and contexts.

Understanding kubeconfig Structure

A kubeconfig file has three main sections:

clusters:       # API server endpoints and CA certificates
users:          # Authentication credentials (tokens, certs, exec plugins)
contexts:       # Bindings of cluster + user + optional namespace
current-context: # The active context

Running kubectl config view displays all of these merged from every file in the KUBECONFIG environment variable (or the default ~/.kube/config).

Working with Minified Output

The --minify flag restricts the output to only the cluster, user, and context relevant to the current context. This is especially useful when you have dozens of contexts configured:

# Full config might show 20 clusters — minify shows only the active one
kubectl config view --minify

# Combine with jsonpath to extract specific values
kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}'
# Output: https://10.0.0.1:6443

# Get the current user name
kubectl config view --minify -o jsonpath='{.users[0].name}'

Extracting a Portable kubeconfig

When you need to share access to a single cluster, you can generate a self-contained kubeconfig:

# Flatten resolves file references into inline data
kubectl config view --minify --flatten --raw > /tmp/portable-kubeconfig.yaml

# Verify it works independently
KUBECONFIG=/tmp/portable-kubeconfig.yaml kubectl get nodes

The --flatten flag inlines any external certificate files, and --raw ensures the actual credential bytes are included rather than the default DATA+OMITTED placeholder.

The KUBECONFIG Environment Variable

kubectl merges multiple kubeconfig files specified in the KUBECONFIG environment variable:

# Linux/macOS — colon-separated
export KUBECONFIG=~/.kube/config:~/.kube/staging-config:~/.kube/prod-config

# View the merged result
kubectl config view

This merge behavior is powerful for teams that distribute per-cluster config files. However, it can also cause confusion when an unexpected file alters the merged output.

Security Best Practices

By default, kubectl config view redacts sensitive fields:

users:
- name: admin
  user:
    client-certificate-data: DATA+OMITTED
    client-key-data: DATA+OMITTED

Always be careful with --raw:

• Never paste --raw output into public issue trackers.
• Rotate credentials if they are accidentally exposed.
• Use RBAC service accounts with limited permissions instead of admin certificates when possible.

Debugging Authentication Issues

When kubectl cannot authenticate, use config view as the first diagnostic step:

# 1. Check which context is active
kubectl config view --minify -o jsonpath='{.current-context}'

# 2. Verify the server URL
kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}'

# 3. Check the auth method (token, cert, exec)
kubectl config view --minify -o yaml | grep -A5 "user:"

# 4. If using exec-based auth (e.g., aws-iam-authenticator), verify the command
kubectl config view --minify -o jsonpath='{.users[0].user.exec.command}'

JSON Output for Scripting

For automation, JSON output combined with jq is more reliable than parsing YAML:

# List all cluster names
kubectl config view -o json | jq -r '.clusters[].name'

# Get server URL for a specific context
kubectl config view -o json | jq -r '.clusters[] | select(.name=="production") | .cluster.server'

This approach is common in CI/CD pipelines where scripts need to validate or switch cluster configuration before deploying workloads.