Skip to content

Cloud IAM (AWS, GCP, Azure)

Add read-only cloud credentials so KubeManta can fetch your VPC / subnet topology and display it alongside your Kubernetes network in the Network view.

What it gives you

  • Multi-cloud topology — see your AWS VPCs, GCP VPCs, or Azure Virtual Networks in the Network view
  • Subnet utilization — view available and used IP addresses per subnet (capacity planning)
  • Combined view — Kubernetes nodes + cloud networking on one diagram
  • No write access — credentials are read-only; KubeManta can never modify your cloud infrastructure

Tier: Free

Prerequisites

One of: - AWS account with credentials (access key / role ARN / IRSA) and permissions to describe VPCs, subnets, and security groups - GCP project with a service account and permissions to describe VPCs and subnets - Azure subscription with credentials (client secret / managed identity) and permissions to describe virtual networks and subnets

Configure in KubeManta

AWS

Option A: Access Key (simplest, dev/test)

  1. In AWS IAM, create a user (or use an existing one):
  2. Name: kubemanta-reader (or your choice)

  3. No console access — programmatic access only (access key + secret)

  4. Attach an inline policy with read-only VPC permissions:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeVpcs",
        "ec2:DescribeSubnets",
        "ec2:DescribeSecurityGroups",
        "ec2:DescribeNetworkInterfaces"
      ],
      "Resource": "*"
    }
  ]
}

  1. Create an access key and save the Access Key ID and Secret Access Key.

  2. In KubeManta, go to Admin → Cloud and select AWS.

  3. Fill in:

  4. Auth Mode: Access Key
  5. Access Key ID and Secret Access Key (from above)

  6. Region: your cluster's region (e.g., us-east-1)

  7. Click Test to verify the credentials work.

  8. Click Save.

Option B: Role ARN + IRSA (production)

If your cluster runs on EKS:

  1. In AWS IAM, create a role for your EKS node (or a separate role):
  2. Trust policy: allow the EKS cluster's OIDC provider + kubemanta-system ServiceAccount

  3. Inline policy: same read-only VPC permissions as above

  4. Note the Role ARN (e.g., arn:aws:iam::123456789:role/kubemanta-reader).

  5. In KubeManta, go to Admin → Cloud and select AWS.

  6. Fill in:

  7. Auth Mode: IAM Role ARN
  8. Role ARN (from above)

  9. Region: your cluster's region

  10. Click Save — KubeManta will use your cluster's IRSA to assume the role.

Option C: STS Temporary Credentials

For short-lived access:

  1. In AWS, use sts:AssumeRole to obtain temporary credentials (Access Key ID + Secret Access Key + Session Token).

  2. In KubeManta, go to Admin → Cloud and select AWS.

  3. Fill in:

  4. Auth Mode: STS Temporary
  5. Access Key ID, Secret Access Key, and Session Token

  6. Region: your region

  7. Click Save. (Credentials expire after a few hours; refresh manually via sts:AssumeRole and update KubeManta.)

GCP

  1. In GCP, create a service account:
  2. Name: kubemanta-reader (or your choice)

  3. Grant the role: Compute Viewer (read-only)

  4. Create a JSON key for the service account and download it.

  5. In KubeManta, go to Admin → Cloud and select GCP.

  6. Fill in:

  7. Auth Mode: Service Account JSON
  8. Service Account JSON: paste the full JSON key

  9. Project ID: your GCP project ID (auto-populated if you paste the JSON)

  10. Click Test to verify.

  11. Click Save. The JSON key is stored encrypted at rest.

Alternative: Workload Identity (GKE)

If your KubeManta cluster is on GKE:

  1. In GCP, create a service account with Compute Viewer role.

  2. Create a workload identity binding: 

    gcloud iam service-accounts add-iam-policy-binding [email protected] \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:PROJECT.svc.id.goog[kubemanta-system/kubemanta-agent]"

  3. Annotate the KubeManta ServiceAccount: 

    kubectl annotate serviceaccount kubemanta-agent -n kubemanta-system \
  iam.gke.io/gcp-service-account=[email protected]

  4. In KubeManta, go to Admin → Cloud and select GCP.

  5. Fill in:

  6. Auth Mode: Workload Identity

  7. Project ID: your GCP project ID

  8. Click Save.

Azure

  1. In Azure, create a service principal (app registration):
  2. Name: kubemanta-reader (or your choice)

  3. Grant the role: Reader (read-only) on the subscription or resource group

  4. Create a client secret and note the Client ID, Client Secret, and Tenant ID.

  5. In KubeManta, go to Admin → Cloud and select Azure.

  6. Fill in:

  7. Auth Mode: Client Secret
  8. Tenant ID, Client ID, Client Secret (from above)

  9. Subscription ID: your Azure subscription

  10. Click Test to verify.

  11. Click Save. The secret is stored encrypted at rest.

Alternative: Managed Identity (AKS)

If your KubeManta cluster is on AKS:

  1. Create a managed identity with Reader role.

  2. Assign the managed identity to the AKS node pool or pod.

  3. In KubeManta, go to Admin → Cloud and select Azure.

  4. Fill in:

  5. Auth Mode: Managed Identity

  6. Subscription ID: your Azure subscription

  7. Click Save. KubeManta will use the pod's managed identity automatically.

Verify

  1. After saving, click Network in the sidebar.
  2. Look for a ☁ Cloud toggle in the top bar.
  3. Click it to show cloud resources.
  4. You should see your VPCs / subnets alongside your Kubernetes nodes.

Expected states

State Meaning Next step
No ☁ Cloud toggle No cloud credentials are configured Follow "Configure in KubeManta" above and save
☁ Cloud toggle present, but cloud view is empty Credentials are saved, but KubeManta couldn't connect or fetch resources Check logs and test credentials again
VPCs and subnets appear Success! Explore subnet utilization, node placement

Troubleshooting

"Test failed" when I click Test

For AWS (Access Key): - Double-check the Access Key ID and Secret Access Key are not truncated or have extra spaces. - Verify the IAM user has the ec2:Describe* permissions in the policy. - Check that the credentials aren't expired or revoked.

For AWS (Role ARN): - Verify the Role ARN is correct and the trust policy allows the cluster's OIDC provider. - Ensure the role has the ec2:Describe* inline policy. - Check that IRSA is properly configured on your cluster.

For GCP: - Paste the full JSON key (it should start with { and end with }). - Verify the service account has Compute Viewer role. - Check that the Project ID in the JSON matches your actual project.

For Azure: - Verify Tenant ID, Client ID, and Client Secret are not truncated. - Ensure the service principal has Reader role on the subscription. - Check that the Client Secret hasn't expired (Azure secrets expire after 2 years by default).

Check KubeManta logs: 

kubectl logs -n kubemanta-system deploy/kubemanta-agent | grep -i cloud

Cloud view is empty but test passed

Did you pick a region / subscription? - AWS: ensure Region is set to where your VPCs are. - Azure: ensure Subscription ID is set to where your VNets are.

Are there VPCs / subnets in that region? - Check your cloud console to confirm resources exist. - KubeManta only shows resources in the configured region/subscription.

Is the cloud credential still valid? - Refresh the page in KubeManta. - If you're using temporary credentials (AWS STS), they may have expired — update them.

Network bandwidth charts still don't appear

Cloud credentials are just for VPC/subnet topology. Network bandwidth requires either: - Prometheus configured (see Prometheus integration) - Or the kubelet cadvisor scrape enabled in Helm (metrics.kubeletScrape.enabled=true)

Cloud IAM doesn't provide bandwidth data.