Skip to main content

Kubernetes

Cyscale enables you to keep track of and secure your Kubernetes resources natively. You connect your Kubernetes clusters by deploying the Cyscale agent. The agent, at its core, is a Kubernetes controller that listens to changes in your cluster, aggregates them, and sends them to Cyscale.

You can connect any type of Kubernetes cluster, including Amazon EKS, Azure Kubernetes Service (AKS), Google Kubernetes Engine (GKE), and self-managed clusters. If you connect EKS, AKS, or GKE clusters, and the corresponding cloud environment is also connected, Cyscale will link the resources helping you understand the infrastructure, networking, and IAM context of your Kubernetes workloads.

Connecting Your Kubernetes Clusters​

You connect your Kubernetes clusters to Cyscale by installing the Helm chart containing the Cyscale Kubernetes agent.

  1. Add the Cyscale Helm repository on your machine:
helm repo add cyscale https://cyscale.github.io/helm-charts
helm repo update
  1. Install/upgrade the chart into the cluster:
helm upgrade -i cyscale -n cyscale --create-namespace --set config.cyscaleAPIKey=<your_key> cyscale/kubernetes-agent

You can choose a different release name (cyscale by default). This is used as a prefix for the resources that will be created such as the deployment, service account, and secret. You can also choose a different namespace in which to install the agent (cyscale by default).

Cyscale identifies your cluster using the API key. This is a unique value for each Kubernetes connector. You can obtain it only during the cluster onboarding and, if you forgot it or want to rotate it, you can always generate a new one and update your release in the cluster using the same helm command from above.

During onboarding, you can also enable Kubernetes vulnerability scanning. When enabled, the Helm command includes the additional setting needed for SBOM collection.

Agent Version Tracking​

Cyscale tracks the installed Kubernetes agent version reported by the cluster connector. Where available, the Connectors page and connector details can show:

  • installed chart or agent version
  • latest available chart or image version
  • whether an upgrade is recommended

Use this information to keep the in-cluster agent current without manually checking the Helm repository every time you review connectors.

Permissions​

The helm chart creates a cluster role and role binding together with a service account.

By default, the agent synchronizes most Kubernetes resources. You can configure this by overwriting the default config.resourcesToScan value from the chart. See values.yaml. Changing this will also change the permissions granted by the cluster role.

Exclusions​

The permission configuration also allows you to exclude certain resources from being processed and sent to the Cyscale application for scanning.

The resource exclusion is done for each entry in the config.resourcesToScan list, meaning you can granularly exclude resources from any GVK (Group Version Kind; E.g., apps/v1/deployments) that you have selected for monitoring.

You can do this in 2 ways:

  1. excludeSelectors - you can define a label selector to be used to exclude assets that match the selector
  2. excludeResources - You can add a list of namespaced names of that GVK to be excluded from the selected assets.
httpClientTimeout: '5s'
cyscaleAPIBaseURL: 'https://app.cyscale.com/collect/kubernetes'
cyscaleAPIKey: ''
resourcesToScan:
  - group: 'apps'
    version: 'v1'
    kind: 'Deployment'
    excludeSelectors:
      - labelSelector:
          matchExpressions:
            - key: 'testKey'
              operator: 'In'
              values:
                - 'testValue'
    excludeResources:
      - name: 'app-name'
        namespace: 'app-namespace'

Vulnerability Scanning​

Cyscale can also scan the container images running in your Kubernetes clusters for package vulnerabilities.

When this option is enabled:

  • the agent discovers the images used by your workloads
  • it generates SBOMs for those images inside the cluster
  • it sends the SBOMs to Cyscale for vulnerability analysis and daily re-scans

This design helps keep the data collection lightweight while still letting Cyscale correlate Kubernetes vulnerabilities with the rest of your cloud and identity context.

If you use private registries, additional registry-specific configuration can be required so the agent can pull the images.

For the vulnerability workflow and prioritization model, see Vulnerability Management.

Network Reachability​

Cyscale can map Kubernetes workload exposure using supported Kubernetes networking resources. This helps answer whether a workload can be reached from outside the cluster and which path exposes it.

Supported exposure signals can include:

  • Ingress rules
  • Ingress default backends
  • services of type LoadBalancer
  • provider-specific links when the Kubernetes cluster is connected together with AWS, Azure, or Google Cloud

Exposure context is used in Inventory, asset details, graphs, and alert prioritization.

AI Workloads in Kubernetes​

Kubernetes is commonly used to host AI runtimes, inference services, agents, vector services, and model-serving workloads. When AI Security is enabled, the Kubernetes agent can help Cyscale identify AI-related workloads based on workload metadata, images, labels, and service context.

See AI Security for how those assets are shown in the AI Security workspace.

Additional Notes​

  • The agent attempts to find out if the cluster is managed based on several heuristics:
    • It attempts to call the GKE metadata server and retrieve the cluster UID, which then Cyscale will use to link it to the actual GKE cluster asset (if you also connected the corresponding Google Cloud project)
    • It attempts to retrieve the FQDN from the KUBERNETES_SERVICE_HOST environment variable set on pods from the kube-system namespace for AKS.
    • It attempts to retrieve the server hostname from the kube-proxy configmap for EKS.
  • For Kubernetes, Cyscale updates the asset inventory in real-time. However, it still updates the relationships between assets (between Kubernetes assets, between the Kubernetes assets and the cloud provider resources, and with the vulnerabilities) as well as assesses the assets against the controls library at specific time intervals. You can also trigger this process manually at any given time.

Further Reading​

If you want more background on how Cyscale approaches Kubernetes risk reduction beyond the connector setup itself, see the Kubernetes Security Guide in the Cyscale Security Wiki. It is useful for understanding how posture findings, image vulnerabilities, IAM context, and runtime exposure should be evaluated together.