Paste a kubeconfig and see every context, cluster and user laid out, with certificate expiry decoded from the certificates themselves. It is parsed in this tab and nothing is uploaded, which is the only reasonable way to inspect a file that is usually a working credential for production.
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Read it. Nothing leaves this tab.
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.
insecure-skip-tls-verify, plus the reminder that a kubeconfig is a live credential
apiVersion: v1
kind: Config
clusters:
- name: prod
cluster:
server: https://1.2.3.4
insecure-skip-tls-verify: true
contexts:
- name: prod
context:
cluster: prod
user: admin
current-context: prod
users:
- name: admin
user:
token: abcThe same file with certificate-authority-data set, which is the fix for a TLS error
apiVersion: v1
kind: Config
clusters:
- name: prod
cluster:
server: https://api.example.com
certificate-authority-data: LS0tLS1CRUdJTg==
contexts:
- name: prod
context:
cluster: prod
user: dev
namespace: app
current-context: prodThese are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
It is a live credential. Anything the file can do, whoever holds it can do, and there is usually no expiry and no audit trail tying it back to a person.
Instead:Give them their own credential. Never paste a kubeconfig into a chat or a ticket.
It disables verification entirely, so any machine-in-the-middle can impersonate the API server and collect the token in the same file.
Instead:Add the cluster CA with certificate-authority-data. The error is usually a missing CA, not a broken one.
Every kubectl command with no explicit context goes there. This is how a delete lands in the wrong cluster.
Instead:Use a prompt that shows the context, and set the namespace per context so a bare command is scoped.
A kubeconfig is the highest-value file most engineers have on disk, and the usual way to inspect one is to paste it into a stranger's website. That is the reason this page exists in a browser: the parse is the easy half.
Read from the certificate itself, not from anything the kubeconfig says, because the kubeconfig says nothing about it. The certificate is parsed here in your browser to pull out its validity period, subject and issuer. An expired one produces a flat Unauthorized with no date anywhere in it, which reads like an RBAC problem for about an hour.
Kubernetes reads RBAC group membership from the certificate's Organisation field, so a certificate can be in system:masters and nothing in the kubeconfig shows it. system:masters is hard-coded above RBAC in the API server: every request is allowed, no binding can restrict it, and it appears in no RBAC audit because there is nothing to audit.
A credential plugin is a program executed locally, as you, every time kubectl needs to authenticate. That is how aws eks get-token works and it is entirely normal. It also means a kubeconfig sent to you by anyone else is arbitrary code execution rather than a list of endpoints, and opening the file warns you about none of it.
A merged kubeconfig that lost one of its source files still lists the context, still shows up in kubectl config get-contexts, and cannot connect. A missing user is worse than a missing cluster: kubectl connects anonymously and returns a 403 naming system:anonymous, which looks like a permissions problem rather than a broken file.
Three independent lists and a pointer. Clusters are where to connect, users are how to authenticate, and contexts pair one of each with a namespace. Nothing validates that the pairs make sense, and nothing in the file indicates how much access it grants.
This is the part worth knowing before anything else. The API server does not check a CRL and does not do OCSP, because neither is implemented. A leaked client certificate is valid until the day it expires and cannot be cancelled. The only remedy is rotating the cluster CA, which invalidates every other certificate signed by it at the same moment, so it is a cluster-wide outage rather than a revocation.
a leaked token delete the Secret, done
a leaked exec config revoke in the identity provider
a leaked client cert rotate the cluster CA, and with
it every other cert in the cluster
which is why a long-lived admin cert in a kubeconfig is
a different class of risk from a long-lived tokenContexts reference clusters and users by string. There is no validation at any point, so a typo produces a context that exists, looks complete and does not work. This is the normal state of a kubeconfig assembled by merging several together, which is what the KUBECONFIG environment variable does.
clusters: [prod, staging]
users: [prod-admin, staging-dev]
contexts:
- name: prod
context:
cluster: prod <- must match a clusters entry
user: prod-admin <- must match a users entry
namespace: apps <- omitted means "default"
current-context: prod <- must match a contexts entrycertificate-authority-data and client-certificate-data hold the base64 of the PEM file, so decoding once gives back PEM text rather than certificate bytes. It is a small detail that catches most homemade parsers, which then report a perfectly good certificate as unreadable.
certificate-authority-data: LS0tLS1CRUdJTiBDRVJU...
base64 -d -> -----BEGIN CERTIFICATE-----
MIIDazCCAlOgAwIBAgIU...
-----END CERTIFICATE-----
then base64 -d again -> the DER bytesEntries can reference files on disk instead of embedding them. That is better for a workstation and it means the file is not self-contained: copied elsewhere it looks complete and fails to connect. Flattening inlines everything, which makes it portable and makes it a complete credential in one file.
kubectl config view --flatten # inline everything
kubectl config view --minify # only the current context
# both together is the right way to hand someone access
# to exactly one cluster, and the result is a credential.
# Treat it like a private key.