Vanta lists and can perform tests on Azure Kubernetes Service clusters and individual nodes, but this requires certain cluster configurations.

How does the integration work?

Azure Kubernetes Service clusters are listed by Vanta and shown in inventory. They don’t require additional configuration and act as any other Vanta resource. Vanta can also list Azure Kubernetes Service individual nodes and several specific tests have been performed on them. Specific cluster settings are required so that the nodes can be listed. In the Vanta app, the listing of the nodes can be enabled or disabled by toggling the corresponding product. Clusters will always be listed regardless of this setting. 

Requirements to list individual Kubernetes nodes 

Vanta’s servers perform Kubernetes API requests to a cluster’s control plane API to list individual Kubernetes nodes and get their configuration. There are some extra requirements for Vanta to be able to do so.

• Enable access to the cluster’s control plane API from the IP Vanta uses for its scanners.
  • This requires that the cluster enables public access to its control plane API (in other words, it is not a private cluster). Node configuration scanning of private clusters is not supported in Vanta since their control API can only be accessed from within the cluster’s private network, rendering simple remote node configuration scanning impossible.
  • To secure a cluster with public access to its control API, a CIDR range filter containing at least the Vanta IP range should be added to its control plane API networking restrictions.
  • If the cluster is private, Vanta will skip listing its nodes. The cluster will be listed properly in Inventory, and no errors will appear in the Vanta app. The tests specific to Kubernetes nodes won’t apply to these clusters, and custom tests won’t be used either since the nodes are not listed for that cluster. 
• Assign the 'Azure Kubernetes Service Cluster User Role' to the Application linked in Vanta. 
  • This is required to fetch the cluster certificate authority, which is required to list nodes and their configuration using the Kubernetes API. If this role is not assigned, a specific error will show in the Kubernetes nodes with the errors section in Inventory.

• Set the cluster to use Microsoft Entra ID for RBAC. This is needed so that the application linked in Vanta Azure credentials can be used to authenticate to the cluster control plane.
• Grant permissions in the cluster control plane to the Azure Application linked in Vanta to list and get individual Kubernetes nodes, by adding the required YAML to create a clusterrole with the required permissions in each cluster and a clusterrolebinding to bind it to the Application. If the clusterrole or the clusterrolebinding is missing or wrong, a generic authentication error will be shown.

• The steps to fulfill each requirement are described in detail in the Vanta Azure integration linking flow. They can be accomplished through the Azure portal or a script provided to run from the Azure Cloud Shell.
• In addition to the specific errors in Kubernetes nodes with errors section in Inventory, if some of the requirements are not fulfilled, the integration page may show an error for the Azure Kubernetes Service nodes