AWS and Kubernetes
Connect AWS account operations and EKS workloads, logs and deployment tools.
Connect AWS once for account operations, with optional Kubernetes/EKS tools for workloads and pod logs. Both capabilities share the same credential, profile grants and write policy. Engineering, Operator and Chat have access by default; you control their grants and enabled tools.
Connect
- Open AWS in Integrations.
- Enter the 12-digit AWS account ID and region.
- Enter an access key ID and secret access key. Include a session token for temporary credentials.
- Choose Read-only, Ask before writes, or Autonomous, then connect.
- For Kubernetes, enable Kubernetes/EKS in the AWS configuration. Give that same identity an EKS access entry and the namespace permissions your work requires. Verify an actual workload or pod-log read after saving. Enabling this capability does not grant cloud permissions.
Use a dedicated identity with only the permissions your work needs; do not copy a person’s AWS credentials or attach administrator policies to connect. Access can be rotated or revoked independently. AWS credentials remain encrypted on the backend and are never placed in agent workspaces. Temporary credentials expire and need replacement. The account check prevents accidentally connecting credentials owned by another account; IAM remains the authority for resources and any cross-account role access.
The general AWS server connects through its US East endpoint and can perform operations in other regions. Kubernetes tools use the region selected in the connection. This connector currently supports commercial AWS endpoints, not GovCloud or China endpoints.
Choose permissions
Start with named resources and specific operations. For development work, that usually means cluster information, pod logs and workload checks in one development namespace, plus any required updates to named development workloads or Lambda functions. Add S3 only for a bucket and folder the task actually needs. Keep production changes and permission management outside that identity.
Use namespace-scoped Kubernetes roles for EKS. Connecting does not require cluster administrator
access. Likewise, AWS script support does not require AdministratorAccess, wildcard service
actions or permission to create roles. Keep the one-time administrator who configures access
separate from the identity Oblive uses afterward. Verify both an allowed development operation and
denied access to production or permission changes before enabling autonomous operations.
EKS MCP invocation permissions are separate from the underlying cluster permissions; AWS currently
requires Resource: "*" for those specific invocation actions. Classic CloudWatch metric reads also
need a broad resource field for cloudwatch:GetMetricData; restrict the region and keep collection
selections explicit. Resource selection limits Oblive’s collector, not every possible API call that
the credential could authorize. Do not grant unrelated service actions to make these reads work.
See the EKS MCP permissions reference and CloudWatch permissions reference.
Reads, writes and logs
EKS provides resource inspection, events, current and previous pod logs, CloudWatch reads, and resource-management tools. Agents request a bounded log window and keep private log contents out of public summaries. Loki is not required for current pod logs; retained Loki history needs its own connection.
AWS account operations use the provider’s remote script tool. Because a script can change resources, Oblive treats every script submission as a write and records it through the existing action service. Read-only mode exposes the reviewed documentation and lookup tools, but cannot run arbitrary scripts. Use EKS read tools for Kubernetes diagnosis without submitting a script. Generated signed URLs also follow the write policy because they delegate access to a resource.
A successful submission is not proof that the requested operation finished. AWS scripts may return a job ID; the agent must poll that existing job and inspect the recorded API results. Failed scripts are reported as failed operations even when the MCP transport returns HTTP success. An uncertain write is not automatically replayed.
Deployment rules
Full cloud access does not approve a production deployment. Engineering reads your saved operating rules and obtains human review when those rules require it. This is an agent instruction; the connector does not infer which arbitrary AWS scripts or Kubernetes resources represent production. Use IAM restrictions and Ask before writes when you need a separate enforced restriction.
The agent image includes a checksum-pinned kubectl for local manifest work. Authenticated account
and Kubernetes operations use the managed tools; there is no provider key or authenticated kubeconfig
in the agent workspace. Repository deployment workflows remain the preferred route for changes.
Selected metrics
Collection is off until you add resources under Connection → Metrics. Add only the resource names or IDs, regions and environments you want to follow. You can select at most 20 per connection. AWS supports Lambda functions, EC2 instances, RDS databases, application load balancers, EKS clusters and S3 buckets. The Kubernetes capability does not enable metric collection; choose each resource explicitly, including any cluster you want to monitor.
| Resource | Collected metrics |
|---|---|
| Lambda function | Invocations, errors, throttles and average duration |
| EC2 instance | Average CPU usage and peak failed status checks |
| RDS database | Average CPU usage and connections |
| Application load balancer | Requests, load balancer server errors and average target response time |
| EKS cluster | Peak failed nodes and average node count |
| S3 bucket | Standard storage bytes and stored object/version count |
Each collection reads only the exact selected CloudWatch dimensions. It does not list all account resources, search metric namespaces, enable monitoring, or install an agent. EKS metrics require existing Container Insights. S3 reports daily storage values without enabling request metrics or listing bucket contents. Byte usage covers Standard storage only. The object count includes all storage classes, retained versions, delete markers and unfinished upload parts; it is not a count of unique customer files. See the S3 metric definitions. No datapoint means unavailable, not zero. Check the selection and reporting setup if data is absent.
Hourly refreshes retain daily values in Oblive’s existing Parquet history. Initial collection and reconciliation cover at most 30 previous days plus the current day; the current day is provisional. Counts add across days. Averages and peaks use the latest daily value in summaries, rather than inventing a combined average across days or resources. Use the daily series and resource filters for comparisons. Agents and people use the same authorized Insights query path.
Removing a resource stops future reads and immediately excludes its retained history from current queries. Full operational access does not broaden metric collection. AWS’s normal CloudWatch API charges still apply to selected reads. Connection checks verify account authentication and available tools; an actual read establishes access to the selected resource.
See the AWS MCP documentation and EKS MCP documentation for provider capabilities and IAM setup.
Existing separate EKS connections
The separate AWS EKS catalog entry is retired. Enable Kubernetes/EKS in your AWS connection after checking that its identity has the intended cluster permissions. Preserve the existing write policy and profile grants; credentials from different accounts are never merged automatically. Verify the new connection, then disconnect the retired entry. Its task and action history stays available; retired entries leave the integration directory once their credentials are removed.