Replies: 1 comment
-
|
imo cloud specific implementations for accessing a kube cluster should live in their respective intel modules. those modules then delegate to the kube intel module, which should just be responsible for one thing: ingest kube resources using the kube api. EKS, for instance, has the access entries API to make it easier for an IAM role to access the cluster. the aws intel module already has all the orchestration logic to traverse multiple accounts and regions, so when it finds an EKS cluster, it can pass control to the kube intel module to ingest those resources. if someone just wants kube resources in their graph but their cluster is behind a managed service they should be able to just run a small part of the aws sync by doing something like: |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Ingesting Kubernetes resources into the graph via the
kubernetesintelmodule can be cumbersome. Users have to add the cartography IAM role to the cluster and ensure it has the correct permissions. Also, if the cluster in question has a private API server, users have to configure their network so that the cartography service can access that private IP.GCP offers Cloud Asset Inventory that allows us to list GKE resources without connecting to the cluster and without adding the cartography IAM role to the cluster. This makes it way easier to get Kubernetes nodes into Cartography and allows users to get value out of the tool more quickly.
Notes:
Some open questions:
Actually that's the only question I have. Thoughts?
cc @ishaanverma @heryxpc @jychp
Beta Was this translation helpful? Give feedback.
All reactions