Cloud connectors
Let Kobi read the AWS and Azure resources a workload depends on — read-only, through curated MCP servers. What each edition includes, how to set it up, and what stays out.
Kobi sees inside the cluster. When a workload fails because of something outside it — a stopped database, a removed firewall rule, a queue full of dead letters, a quota that blocks a node pool — the evidence in Kubernetes stops at “cannot connect”. Cloud connectors let Kobi read those resources in your cloud account. On Cloud and EE, Autopilot’s investigator, planner and postmortem read them too.
Connectors shipped in KubeBolt 2.5.0 (open source) and 2.5.0-e2 (Cloud and EE self-hosted).
What each edition includes
| Open source | KubeBolt Cloud | EE self-hosted | |
|---|---|---|---|
| Amazon Web Services | ✅ | ✅ From the Team plan | ✅ |
| Microsoft Azure | ✅ Through a sidecar | Soon | Soon |
| Google Cloud | Soon | Soon | Soon |
- Plans. On KubeBolt Cloud, connectors start at Team. On Free the card shows a lock, and Preview opens what the connector reads and how it is set up. Self-hosted installs are never gated by plan.
- Why Azure is Soon outside open source. The Azure MCP Server signs in with one service principal per instance, so it cannot give each organization its own identity. A connector listed as Soon has nothing to set up, and Kobi and Autopilot have no tools for it.
What it reads
- AWS: EKS and the EC2 and Auto Scaling behind its nodes, RDS and Aurora, CloudWatch, load balancers and target health, security groups, network ACLs, route tables and Route 53, ElastiCache, SQS, SNS, MSK, Lambda, KMS, S3 bucket settings, Secrets Manager metadata, CloudTrail, AWS Health, Service Quotas, IAM roles and ECR.
- Azure: the activity log, platform metrics, Resource Health, PostgreSQL, MySQL and Azure SQL servers, AKS, quotas, Service Bus, Event Hubs, Container Registry, Key Vault expiry, storage settings, Log Analytics and Advisor.
Read-only, in layers
Read-only is enforced, not promised:
- Only curated tools exist. Each connector has an allowlist, checked again at call time. A tool that isn’t listed isn’t in the model’s catalog.
- The model writes no code. For AWS, Kobi asks for a typed operation, and KubeBolt renders it into a fixed read script and checks afterwards that exactly that API ran. For Azure, every value is type- and path-checked before it reaches the sidecar.
- Your role says no too. The AWS permissions policy the setup guide prints denies secret values, S3 object contents, database queries and instance user data, even if a broader policy is attached to the role later.
- Results are data. They reach the model redacted, capped at 32 KiB and marked as data, never as instructions.
- Every call is recorded. Each one leaves an access record (
mcp_tool_call) in Administration › Actions, without its arguments or its response.
Limits: 12 cloud calls per Kobi question, 40 per Autopilot run, 120 per minute per organization and 30 s per call.
Set up AWS
Connectors live in Administration › AI & Autopilot › Connectors on Cloud and EE, and in Administration › AI (Kobi) › Connectors in open source.
- Open Amazon Web Services. The drawer prints the role’s permissions and trust policies, with your organization’s External ID already in them, and the CLI commands that create it.
- Create the role in your AWS account.
- Paste the role ARN and the region, then Test connection.
- Save and enable the connector.
The External ID is generated once per organization and shown read-only. It is kept when you remove the connector, so setting it up again prints the same ID and the role keeps working.
On KubeBolt Cloud
The assumed role is the only mode, and two kinds of role are refused:
- A role in KubeBolt’s own AWS account.
- A role that doesn’t require the External ID. AWS ignores an External ID the trust policy doesn’t ask for, so such a role would be open, through KubeBolt, to any organization that learned its ARN.
To check that second one, KubeBolt tries to assume your role without the
External ID and with a deny-all session policy, before first using it and every
hour after that. AWS must refuse. Your CloudTrail shows each check as a denied
AssumeRole from the session kubebolt-external-id-check. That is expected.
When you self-host
- On EKS: give the API’s ServiceAccount an IAM role (IRSA or Pod Identity) and
set
mcpConnectors.aws.principalArnto it, so the printed trust policy names it. - Outside EKS, on EE: set
mcpConnectors.aws.webIdentity.enabled=true, withprincipalArnpointing at a role that trusts this cluster’s OIDC issuer for the API’s ServiceAccount. - Or use This machine’s credentials: KubeBolt signs with the identity it runs with. It only sends the listed reads, but IAM doesn’t restrict that identity, so give it a dedicated read-only one.
Behind an egress firewall, allow AWS STS and aws-mcp.us-east-1.api.aws, or
aws-mcp.eu-central-1.api.aws, the connector’s other host region.
The first call of a session takes 9–12 s while AWS starts its sandbox. Later calls take 2–3 s.
Set up Azure (open source)
The Azure MCP Server runs next to the API and holds a read-only service principal with the Reader, Monitoring Reader and Log Analytics Reader roles. The connector’s setup guide gives the commands to create it.
- Helm: set
mcpConnectors.azure.sidecar.enabled=true, withexistingSecretnaming a Secret that hastenant-id,client-idandclient-secret. It runs as a second container of the API pod, on loopback only, with a read-only root filesystem and no ServiceAccount token. - Docker Compose: run
docker compose --profile azure up -d, with the credentials indeploy/.env.
Then open Microsoft Azure in Connectors, enter the subscription ID, test the connection and save.
To see Resource Health’s current status, someone with Owner or Contributor on the subscription registers the provider once. Registering it creates no resource and is free:
az provider register --namespace Microsoft.ResourceHealth --subscription <id>
Without it, Kobi still sees health events in the activity log.
Who can use a connector
Each connector has a minimum role for the person asking Kobi, set in its drawer: Editors and admins (the default), Everyone or Admins only. A user below it doesn’t get the connector’s tools.
A connector reads the organization’s cloud account for everyone above that role. It is not scoped by team. Autopilot isn’t subject to the minimum role.
Using it
Ask as usual: “orders-api is not ready, why?”. When the evidence points outside the
cluster, Kobi classifies the address with get_external_connections and uses the
matching connector. The steps mark where it leaves the cluster (“Leaves the cluster
→ AWS us-east-2 · read-only”), and the answer ends with a footnote saying what it
read.
To keep questions inside one cluster on a small model, set an escalation model.
Turning it off
mcpConnectors.enabled=false (KUBEBOLT_MCP_CONNECTORS=false) removes the
Connectors tab and the cloud tools. Connectors keep their settings in KubeBolt’s
settings store, so they need authentication on: with it off, there is no Connectors
tab.
Troubleshooting
| Symptom | Cause |
|---|---|
| ”This role can be assumed without your organization’s External ID.” | The trust policy lacks the sts:ExternalId condition. Add it from the printed policy and test again |
| AWS test can’t assume the role after an upgrade | The trust policy still has an older external ID. Copy the generated one from the drawer |
| The card shows a lock and a plan badge | The organization’s plan is below the connector’s minimum |
| Azure test: “Nothing answers at…” | The sidecar isn’t running |
resourcehealth answers 409 | Microsoft.ResourceHealth isn’t registered yet, or is still registering. It took about ten minutes in our test |
| One user’s Kobi doesn’t use a connector | That user’s role is below the connector’s minimum |
| Kobi doesn’t use a connector at all | It isn’t enabled and verified, or in-cluster evidence answered first, which is by design |