Two authorizations, one workflow. Connecting AWS lets ChangeGuard AI discover your EKS fleet. It does not automatically grant Kubernetes access to any cluster — each cluster’s read access is a separate, explicit grant you make in step 4. ChangeGuard AI presents both as one centralized onboarding flow, and never grants itself access.
1. Connect your AWS account
In Fleet → Connect an environment, register your account and create one IAM role from the trust policy shown. Two properties make this safe:- The role’s only permissions are
eks:ListClustersandeks:DescribeCluster— discovery, nothing else. - Its trust policy requires ChangeGuard AI’s principal and a unique external ID issued by ChangeGuard AI, so no one else can ever have your role assumed — and ChangeGuard AI never accepts an external ID from a caller.
2. Discover your fleet
ChangeGuard AI assumes your role with a short-lived (15-minute) session and lists the EKS clusters it can see, per region. Discovery registers nothing — you choose scope before anything is observed.3. Select clusters
Pick the clusters ChangeGuard AI may observe. Registering them creates observation targets; no access exists yet.4. Authorize read-only access
ChangeGuard AI generates the exact authorization for your selection: one EKS access entry per cluster mapping ChangeGuard AI’s assumed role to a Kubernetes group, plus one read-only role granting that groupget/list on the resources judgment needs. You run it with your own credentials — and the same script pattern covers one cluster or a hundred.
The grant is read-only by construction: get/list only, no watch, no write verbs, no wildcards, and no Secret access is requested. Removing the access entry or the role binding revokes ChangeGuard AI within about a minute.
5. Verify
Each target shows connected under Access & Trust once its first evidence arrives — typically within a minute of authorization.6. Your first live-evidence judgment
From the first collection on, judgments against these clusters carry live environment context. For example, ChangeGuard AI can catch a proposed workload change that would exceed the namespace’s available Kubernetes ResourceQuota — before the change executes — and return a BLOCK with the exact arithmetic. Wire the verdict into your pipeline with Use the Verdict in CI.How Fleet handles credentials
- Every AWS session is minted per operation via STS AssumeRole and expires on its own (15 minutes).
- Kubernetes authentication uses a short-lived bearer minted per collection cycle, held only in memory — never written to disk, never logged.
- No long-lived customer keys are ever accepted or stored. The stored record is non-secret configuration (role ARN, external ID, regions).
- Revoking the trust policy, the access entry, or the role binding takes effect within the next collection cycle.
Evidence freshness
ChangeGuard AI does not treat stale environment state as current evidence. If it cannot establish that the environment evidence is recent enough to support a clean judgment, the verdict says so — missing or stale evidence surfaces as an honest HOLD, never a silent pass.One cluster or a hundred
Observation is managed centrally: discover the fleet, select the clusters, authorize them through the generated bulk workflow, and ChangeGuard AI handles ongoing collection — with no ChangeGuard installation in any cluster, and a broken or unreachable cluster never stopping collection from the healthy ones.Need node-local evidence? Runtime signals (Falco) and node benchmarks (kube-bench) require local presence, and some environments can’t be reached centrally. That’s what the optional ChangeGuard Edge in-cluster install is for — see ChangeGuard Edge. Fleet by default; Edge when the evidence has to stay local.