Vulnerabilities
kubeconfig vs .env on Production Origins
July 25, 2024
kubeconfig vs .env on a production origin is two secret stores that must never be public objects. /.env is live app credentials — the roast already signatures that path. A reachable kubeconfig is cluster-access material: server URLs, certificate data, and often a user token. Serving it next to index.html is the same class of miss as /.env. RoastMyOpsec may not fetch kubeconfig today. Still deny the name at the edge. Do not put it in robots.txt Disallow; that is a map, not a lock.
The practical difference
.env is what the web app loads at boot. kubeconfig is what kubectl and controllers use to talk to a cluster. Different runtimes, same rule: the CDN is not a home folder.
A 'redacted' kubeconfig that still names the API server and context is an inventory leak. A full file is a credential incident. Treat a public hit as rotate-and-deny, not as a debate about YAML.
How to choose based on what you shipped
If the file landed on the origin: take it off the bucket, deny the basename at the CDN, rotate cluster credentials that may have been in that tree, and stop copying operator laptops into static deploys. CI should fail if kubeconfig-shaped names appear in the marketing artifact.
| Option | When it wins | Watch-out | Takeaway |
|---|---|---|---|
| .env on the origin | Never | Live app secrets | Incident; roast signatures this path |
| kubeconfig on the origin | Never | Cluster access material | Same class of miss; deny the name |
| kubeconfig on a laptop / CI secret | Private admin paths you control | Do not zip it into the web root | Keep off every public object store |
| robots.txt Disallow | Crawl waste only | Advertises the filename | Edge deny, not a robots line |
When each store wins (always off the CDN)
.env wins as a server-only file or injected platform secret for the app. kubeconfig wins as a tightly held admin file or cloud identity, never as a static asset. Neither wins on a brochure origin.
Preview deployments and 'temporary' buckets get the same rule. A 404 on /.env does not prove kubeconfig is gone.
Common mistakes
The first mistake is dropping a kubeconfig into the frontend repo 'so local k8s demos work' and then publishing that repo as the site.
The second mistake is rotating app .env values and ignoring cluster credentials because 'the roast did not mention kubeconfig.'
The third mistake is listing the filename in robots.txt instead of denying it at the CDN.
What a URL roast can prove
RoastMyOpsec signatures /.env and /.env.local with bounded GETs. kubeconfig is not a scored path today. Still deny it. A clean check is not a guarantee a uniquely named config is absent. No cluster API calls, no credential use.
Free audit the URL you own
RoastMyOpsec is a defensive public-surface roast: headers, cookies, sensitive paths, and more — no exploit payloads. Start with the free audit, then open the vault if the blurred findings look expensive.
Free audit nowFAQ
- Is a public kubeconfig a vulnerability?
- Yes — treat it as a credential-adjacent exposure. Remove it, deny the name at the edge, and rotate cluster access that may have been in the file.
- Does RoastMyOpsec fetch kubeconfig?
- Not as a scored path today. It does probe /.env. Deny kubeconfig at the CDN anyway. Same class of miss as /.env.
- Can I keep a 'stripped' kubeconfig on the marketing site?
- No. Cluster endpoints and context names are still a map. Public origins do not host admin files.
Sources
Related guides
Vulnerabilities
Exposed .git vs .env on Production WebsitesVulnerabilities
.env.example vs .env on Production OriginsVulnerabilities
Public JavaScript API Keys vs Server Secrets