Kubernetes Remote Scanner
Copy link

Cloud Security (InsightCloudSec)’s new Kubernetes Remote Scanner expands our existing Kubernetes Security Guardrails and Container Vulnerability Assessment capabilities by improving Cloud Security (InsightCloudSec)’s agentless approach for better usability and simplified operation of harvesting Kubernetes entities that exist within different Kubernetes clusters running across different cloud accounts. This solution currently only works with managed clusters.

Feature Overview
Copy link

  • Cloud Security (InsightCloudSec) harvests the Kubernetes services via the cloud provider API and creates a Kubernetes cluster entry linked under your cloud account.
  • Cluster access is generated using the account access credentials provided by the user.
  • Cluster resources are harvested and associated with the parent cloud account.
  • Cloud Security (InsightCloudSec) automatically performs a scan, repeating scans periodically at a defined interval.
  • Cloud Security (InsightCloudSec) automatically synchronizes the badges associated with the cloud account that contains the Kubernetes service and the tags associated with the Kubernetes cluster into the cloud account that represents the cluster. This allows the user to filter the Kubernetes resources and insights using these badges and tags.
  • To migrate between scanners, refer to the instructions on the Clusters Account Setup & Management page.

Prerequisites & Deployment
Copy link

The Kubernetes Remote Scanner requires the appropriate configuration and permissions for your desired Cloud Service Provider (CSP) accounts (e.g., EKS, AKS) in order to harvest and populate cloud accounts built on the data associated with your clusters. Before getting started with the Kubernetes Remote Scanner you will need to ensure you have the following:

  • An existing Cloud Security (InsightCloudSec) installation (version 22.10.26 or later)
  • Appropriate permissions for your desired Cloud Service Providers in order to harvest the resource information specific to each provider
  • An existing Kubernetes cluster with network access available to Cloud Security (InsightCloudSec)
    • Ports 443 and 6443 are used for communications from Cloud Security (InsightCloudSec) to Kubernetes clusters
    • In general, we recommend that Network access be provided through a dedicated access list for Cloud Security (InsightCloudSec)

Configuring Permissions
Copy link

Depending on your preferred cloud service providers, you must provision the following permissions to enable the Kubernetes Remote Scanner.

ℹ️

Subjectaccessreview Details

For more information on the subjectaccessreview permission, see the Kubernetes Scanners Overview FAQ.

AWS

The following permissions are required for Cloud Security (InsightCloudSec) to access the Elastic Kubernetes Service (EKS):

"eks:DescribeCluster", "eks:ListClusters"

Azure

The following permissions are required for Cloud Security (InsightCloudSec) to retrieve the credentials needed to authenticate and connect to AKS clusters for scanning purposes:

"actions": [ "Microsoft.ContainerService/managedClusters/listClusterUserCredential/action", "Microsoft.ContainerService/managedClusters/read" ]

The following data-level permissions are required for Cloud Security (InsightCloudSec) to read all cluster resources and create subjectaccessreviews to validate access permissions within the Kubernetes cluster:

"dataActions": [ "Microsoft.ContainerService/managedClusters/*/read", "Microsoft.ContainerService/managedClusters/authorization.k8s.io/subjectaccessreviews/write" ]

GCP

The following permissions/roles are needed for a service account in order to scan a Kubernetes cluster in the Google Kubernetes Engine (GKE):

  • Kubernetes Engine Cluster Viewer (roles/container.clusterViewer)
    • Provides access to get and list GKE clusters and get cluster credentials.
    • Note: This role is a subset of the Kubernetes Engine Viewer role (roles/container.viewer)
    • Provides permissions: container.clusters.get, container.clusters.list, resourcemanager.projects.get, resourcemanager.projects.list
  • Kubernetes Engine Viewer (roles/container.viewer)
    • Provides read-only access to resources within GKE clusters, such as nodes, pods, and GKE API objects
    • Review the GCP documentation  for more information about the permissions this role provides
  • Permission needed for secrets visibility and validation: container.secrets.list
  • Permission needed for subjectaccessreview creation: container.subjectAccessReviews.create
ℹ️

Onboarding Roles

One of the recommended roles for onboarding a GCP account, the Viewer role (roles/viewer), includes most of the permissions above.

Configuring Kubernetes Access
Copy link

Currently, Cloud Security (InsightCloudSec) offers support for the following CSPs and their Kubernetes service equivalents:

AWS (EKS)
Copy link

To enable access for EKS, you need to create an access entry for your cluster using your existing AWS IAM Cloud Security (InsightCloudSec) Harvester role or a new (dedicated, separate) AWS role for Cloud Security (InsightCloudSec). The most common option is to use your existing AWS IAM Role and update the access entries to provide read access to EKS cluster resources.

⚠️

Authentication mode requirement

The authentication mode of your cluster must be configured to enable access entries.

Option 2: Configure a new AWS IAM role

ℹ️

Trust policy required

If you use a different role than your existing harvesting role, the new role must have the same AssumeRolePolicy (trust policy) as the harvesting role (for example, arn:aws:iam::{account_id}:role/rapid7-consolidated).

To configure a new AWS IAM role:

  1. Log in to Cloud Security (InsightCloudSec).

  2. Go to Cloud > Cloud Accounts and click the target account’s name.

  3. Go to Settings > Additional Settings

  4. In the Update EKS Scanner Role section, select or create a new separate role.

  5. Click Save.

  6. Log in to the AWS console  for the target account.

  7. Open the AWS CloudShell.

  8. Create the access entry for the new role:

    aws eks create-access-entry --cluster-name {your-cluster-name} --principal-arn arn:aws:iam::{account-id}:role/rapid7/{your-role-name}
  9. Associate the AmazonEKSAdminViewPolicy with the access entry:

    aws eks associate-access-policy --cluster-name {your-cluster-name} --principal-arn arn:aws:iam::{account-id}:role/rapid7/{your-role-name} --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy --access-scope type=cluster

Once you complete the steps to provide Read Access Permissions to EKS, Kubernetes access will be configured and the cluster will begin harvesting (assuming it is not in a paused state in Cloud Security (InsightCloudSec)).

Azure (AKS)
Copy link

To enable Azure Kubernetes Service (AKS) access for InsightCloudSec (Cloud Security), you need to update the permissions for your existing Cloud Security (InsightCloudSec) Azure Application from Azure - Onboarding. The easiest way to update permissions is by creating and assigning a new custom role, which you can do using the Azure CLI or Azure Portal.

⚠️

Existing Azure Application

If you do not have an Azure account onboarded with Cloud Security (InsightCloudSec), you will need to follow those instructions to setup an application and apply the necessary roles.

Option 2: Create a custom role using the Azure Portal

ℹ️

Finding Your Application ID

You’ll need your Azure application ID before you can create and assign the custom role. To find your application ID, go to Azure Active Directory > App registrations in the Azure Portal.

To create and assign a custom role using the Azure Portal:

  1. Log in to the Azure Portal  as an admin user for the account that hosts your Cloud Security (InsightCloudSec) Application.
  2. Find your subscription, then go to Access control (IAM) > Roles.
  3. Click + Add > Add custom role
  4. Enter the Basics:
    • Name: ICS Kubernetes Read All/Create subjectaccessreview
    • Description: Role that allows a user to read all resources on a Kubernetes cluster and create subjectaccessreviews
    • Assignable scope: Select your subscription.
  5. Click the Permissions tab.
  6. Click Add permissions and add the following:
    • Actions:
      • Microsoft.ContainerService/managedClusters/listClusterUserCredential/action
      • Microsoft.ContainerService/managedClusters/read
    • Data Actions:
      • Microsoft.ContainerService/managedClusters/*/read
      • Microsoft.ContainerService/managedClusters/authorization.k8s.io/subjectaccessreviews/write
  7. Click Review + create to create the role.
  8. Go to Access control (IAM).
  9. Click + Add > Add role assignment.
  10. Search for and select the new ICS Kubernetes Read All/Create subjectaccessreview role.
  11. Click Next.
  12. For the Members:
    • Leave Assign access to as the default (User, group, or service principal).
    • Click + Select members.
    • Search for and select your InsightCloudSec Azure Application. Click Select.
  13. Click Review + assign to complete the role assignment.

Kubernetes access is now configured and the cluster will begin harvesting (assuming it is not in a paused state in Cloud Security (InsightCloudSec)).

GCP (GKE)
Copy link

To enable access for GKE you will need to update your existing Cloud Security (InsightCloudSec) GCP Project (from GCP - Onboarding) to include the permissions/roles mentioned in Configuring Permissions.

⚠️

Existing GCP Project

If you do not have an GCP project onboarded with Cloud Security (InsightCloudSec), you will need to follow those instructions to setup an application and apply the necessubjectaccessreviewy roles.

  1. Within your GCP console navigate into the project that is associated with Cloud Security (InsightCloudSec).
  2. Navigate to IAM & Admin>Roles.
  3. Edit the role associated with Cloud Security (InsightCloudSec).
    • Find the role and click the vertical three dots to expose the menu.
    • Click Edit.
    • Click + ADD PERMISSIONS.
    • Filter for the "container.secrets.list" permission and select the checkbox next to it.
    • Click ADD.

Once you complete the steps to provide Read Access Permissions to GKE, Kubernetes access will be configured and the cluster will begin harvesting (assuming it is not in a paused state within Cloud Security (InsightCloudSec)).

What’s Next?
Copy link

Refer to the Kubernetes Security Guardrails Overview page for an overview of this feature and a summary of the prerequisites.

Jump to the Using Kubernetes Security Guardrails page to view details on using the feature and exploring the imported data.