Kubernetes considerations
Trust Architecture Playbook: Baseline pillar
Kubernetes environments don't follow the same certificate patterns as traditional infrastructure, and the discovery strategies required reflect those differences. Certificates can be served by ingress controllers or cloud load balancers sitting in front of the cluster, while the actual certificate material may live in Kubernetes secrets, external vaults, or both.
It's like a building inspector evaluating a skyscraper based only on what they can see from the street. The entrance points are identifiable, but there is no visibility inside the building. You need visibility into each layer to know what you have.
This means discovery in Kubernetes requires a layered approach: ingress-level connector coverage to catch what's being served, combined with secrets scanning to surface what's stored. Neither alone gives you the full picture — and in a dynamic environment where workloads spin up and down continuously, gaps in coverage translate directly into gaps in your inventory.
Recommended discovery coverage model
External ingress: Use cloud scans and CT logs monitoring for public DNS names; use cloud connectors for cloud load balancers/certificate services.
Internal gateways/service mesh ingress: Use network scanning (where approved) and targeted system scans as needed.
Automation-aware inventory: Assign tags by cluster/namespace and align ownership to the service owner, not solely the platform team.