Why We Stopped Asking for Your Cloud Credentials

Every Kubernetes monitoring tool eventually asks the same uncomfortable question: "Can we have your cloud credentials?"

IAM keys, service account JSON files, client secrets — the implicit assumption has always been that the analysis tool needs cloud-level access to do its job. Your security team winces. You create a "read-only" role and hope for the best. The keys get rotated on a good month.

We built KorPro's original architecture exactly this way. And after shipping it, we decided to tear it out entirely.

Here's why — and what we replaced it with.

The Problem With the Server-Side Model

The original KorPro model worked like this:

1. You provide GCP/AWS/Azure credentials to the KorPro platform.
2. Our servers use those credentials to discover your clusters.
3. We connect to each cluster, pull resource data, and return findings.

On paper, this is "read-only access." In practice, it has several hard problems.

1. You're Extending Trust Across a Network Boundary

When you hand credentials to any SaaS platform, you are making a statement: I trust that this external system, its employees, its cloud infrastructure, and any future breach of that infrastructure will never misuse my access.

That's a large blast radius for a monitoring tool. A compromised SaaS vendor doesn't just lose your data — in this model, they have the keys to enumerate your entire cloud infrastructure.

2. Credentials Are Stored, Rotated, and Managed Externally

Cloud credentials require lifecycle management: rotation, revocation, auditing. When they live in an external system, that lifecycle is partially out of your control. Many teams solve this by creating long-lived keys and rarely rotating them — the worst possible outcome from a security posture perspective.

3. Cross-Account IAM Is Genuinely Complex

Getting EKS access right, for example, requires IAM policies and EKS access entries and access policy attachments. Each step is a place where a misconfiguration can silently fail or silently over-grant. Platform teams have to become experts in a permission model they only configure once per tool.

The In-Cluster Inspector Model: Flip the Trust Direction

The KorPro Inspector inverts the trust model entirely.

Instead of KorPro reaching into your cluster from outside, you deploy a small Go agent inside your cluster. The Inspector runs as a Kubernetes CronJob with read-only RBAC. It scans your cluster from within, then POSTs only the orphan findings to your KorPro dashboard over HTTPS.

Your Cluster                        KorPro Platform
─────────────────────               ─────────────────────
Inspector CronJob                   Dashboard
 │                                   │
 ├── reads K8s API (in-cluster)       │
 ├── builds dependency graph          │
 ├── costs findings                   │
 └── HTTPS POST findings ──────────► receives & stores findings

What leaves your cluster: A JSON payload of orphan findings with resource names, types, namespaces, estimated costs, and health scores.

What never leaves your cluster: Credentials, kubeconfig, node metadata, secrets contents, environment variables, container images, logs.

The Inspector authenticates to the KorPro API using a license key — a string you generate in the dashboard. It has no cloud account access. It cannot enumerate other clusters. It cannot be used to access your cloud provider.

What the Inspector Does With Read-Only RBAC

The Helm install creates a ClusterRole with a specific, auditable set of permissions:

yaml
rules:
  - apiGroups: [""]
    resources:
      - pods
      - services
      - configmaps
      - secrets
      - persistentvolumeclaims
      - serviceaccounts
      - namespaces
      - nodes
    verbs: ["get", "list"]
  - apiGroups: ["apps"]
    resources:
      - deployments
      - replicasets
      - statefulsets
      - daemonsets
    verbs: ["get", "list"]
  - apiGroups: ["rbac.authorization.k8s.io"]
    resources:
      - roles
      - rolebindings
      - clusterroles
      - clusterrolebindings
    verbs: ["get", "list"]

Every verb is get or list. No create, update, delete, or patch. The Inspector cannot modify a single resource in your cluster. If your security team wants to audit the exact permissions before installing, helm template will render the full RBAC manifest locally — no install required.

Auto-Detection Replaces Manual Configuration

One of the frustrating parts of the old model was manual configuration: select your cloud provider, enter your project ID or account ID, choose your regions. This created friction and introduced human error.

The Inspector auto-detects everything from node metadata:

• GKE: reads the GCE metadata server at metadata.google.internal
• EKS: reads the EC2 instance metadata endpoint
• AKS: reads the Azure IMDS endpoint

From these, it extracts the cloud provider, region, and cluster name without any manual input. The first time it posts findings, your cluster appears in the dashboard already labeled correctly — no setup required on the dashboard side.

Offline Fallback: Works Even If the API Is Unreachable

If the KorPro API is unreachable (network policy, temporary outage), the Inspector writes findings to a local JSON file inside the pod before the scan completes. This means:

• No scan data is lost.
• The scan never blocks on API availability.
• You can kubectl cp the JSON from the pod for offline analysis.

What This Means for Your Security Team

The conversation with your security team changes significantly:

Your security team can audit the exact ClusterRole YAML, the exact image digest, and the exact HTTPS endpoint before approving the deployment. There are no credentials to rotate on the KorPro side because KorPro never has any.

The License Key Is Not a Credential

One clarification worth making: the license key the Inspector uses is not a cloud credential and does not grant access to your infrastructure. It gates API access to your KorPro account — think of it like an API token for a reporting endpoint. You can rotate it from the dashboard at any time. Rotating it does not affect any cloud provider permissions because there are none.

One Inspector Per Cluster. No Sidecar. No Daemonset.

The Inspector installs as a single CronJob resource. It runs for 1–3 minutes every 6 hours, does its work, and exits. There is no persistent process, no always-on container consuming resources, no sidecar injected into your application pods.

Resource footprint during a scan: 256Mi RAM, 100m CPU. After the scan completes: 0.

Getting Started

If you want to try the new model:

bash
helm install korpro-inspector oci://ghcr.io/kortechnologies/charts/korpro-inspector \
  --namespace korpro-system \
  --create-namespace \
  --set licenseKey="<your-key>"

Your license key is in the KorPro dashboard under Settings → Inspector, with the full install command pre-filled.

If you prefer not to use Helm, the Inspector is also available as a standalone CLI binary for Linux, macOS, and Windows — no Kubernetes required for a one-shot scan.

Conclusion

The in-cluster model isn't just a security improvement — it's a better architecture. Scans run faster because the Inspector reads the Kubernetes API over localhost. Configuration is eliminated because the Inspector auto-detects everything. The attack surface is smaller because there are no credentials to steal.

We believe this is how Kubernetes analysis tools should work: your infrastructure stays yours, and only the findings you want to see cross the boundary.

---

See It For Yourself

Deploy the Inspector into any cluster and see your first findings in under 5 minutes. Start with a free account — no credit card required, and your license key is ready the moment you sign up. Questions about the security model? Talk to our team.