Kubernetes Configuration

Follow these steps to analyze Kubernetes objects in Cartography.

  1. Configure a kubeconfig file specifying access to one or multiple clusters.

    • Access to multiple Kubernetes clusters can be organized in a single kubeconfig file. Cartography’s Kubernetes intel module will automatically detect that and attempt to sync each cluster.

  2. Note down the path of configured kubeconfig file and pass it to cartography CLI with --k8s-kubeconfig parameter.

Required Permissions

Cartography’s Kubernetes module requires read-only access to the following Kubernetes API calls:

  • get namespaces for reading kube-system cluster metadata

  • list namespaces

  • list pods

  • list services

  • list serviceaccounts

  • list secrets

  • list roles

  • list rolebindings

  • list clusterroles

  • list clusterrolebindings

  • list ingresses

  • get configmaps for reading the aws-auth ConfigMap in kube-system (EKS only)

Create a ClusterRole and bind it to the identity used by Cartography:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cartography-viewer
rules:
# Namespaces - list for namespace sync, get for kube-system cluster metadata
- apiGroups: [""]
  resources:
    - namespaces
  verbs: ["get", "list"]
# Core resources - list only
- apiGroups: [""]
  resources:
    - pods
    - services
    - serviceaccounts
  verbs: ["list"]
# Secrets - Cartography stores metadata only
- apiGroups: [""]
  resources:
    - secrets
  verbs: ["list"]
# RBAC resources
- apiGroups: ["rbac.authorization.k8s.io"]
  resources:
    - roles
    - rolebindings
    - clusterroles
    - clusterrolebindings
  verbs: ["list"]
# Networking resources
- apiGroups: ["networking.k8s.io"]
  resources:
    - ingresses
  verbs: ["list"]
# ConfigMaps (EKS only) - read aws-auth identity mapping
- apiGroups: [""]
  resources:
    - configmaps
  verbs: ["get"]

The /version endpoint (used to detect the cluster version) requires no additional RBAC — it is accessible by default via the system:public-info-viewer ClusterRole.

Additional AWS Permissions for EKS

If you run Cartography against Amazon EKS and set --managed-kubernetes eks, Cartography also enriches cluster access metadata by calling the EKS API for:

  • Access Entries

  • External OIDC identity provider configs

Grant the AWS principal running Cartography these IAM actions on each target cluster:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "eks:ListAccessEntries",
        "eks:DescribeAccessEntry",
        "eks:ListIdentityProviderConfigs",
        "eks:DescribeIdentityProviderConfig"
      ],
      "Resource": "*"
    }
  ]
}

Notes:

  • These AWS permissions are in addition to the Kubernetes RBAC above.

  • Cartography derives the EKS region from the cluster field of each kubeconfig context entry. When using aws eks update-kubeconfig, this field is automatically set to the cluster ARN.

  • If you use aws eks update-kubeconfig to generate the kubeconfig that Cartography consumes, that command also requires eks:DescribeCluster.

TLS Troubleshooting and Validation

When Kubernetes API server cert settings are misconfigured, sync failures can be difficult to diagnose from raw kubeconfig alone. Cartography writes kubeconfig TLS posture fields onto KubernetesCluster so operators can quickly reason about configuration risk.

Preflight checks

Run these commands before syncing:

kubectl config view --raw -o json
kubectl get --raw=/version

Pay attention to contexts where:

  • insecure-skip-tls-verify=true

  • neither certificate-authority nor certificate-authority-data is set

Graph query for TLS posture

MATCH (k:KubernetesCluster)
RETURN k.name, k.api_server_url, k.kubeconfig_tls_configuration_status,
       k.kubeconfig_insecure_skip_tls_verify,
       k.kubeconfig_has_certificate_authority_data,
       k.kubeconfig_has_certificate_authority_file,
       k.kubeconfig_has_client_certificate,
       k.kubeconfig_has_client_key
ORDER BY k.name;