Skip to content

Kubernetes Provider

This page details the Kubernetes provider implementation in Prowler.

By default, Prowler will audit all namespaces in the Kubernetes cluster accessible by the configured context. To configure it, follow the getting started page.

Kubernetes Provider Classes Architecture

The Kubernetes provider implementation follows the general Provider structure. This section focuses on the Kubernetes-specific implementation, highlighting how the generic provider concepts are realized for Kubernetes in Prowler. For a full overview of the provider pattern, base classes, and extension guidelines, see Provider documentation.

KubernetesProvider (Main Class)

  • Location: prowler/providers/kubernetes/kubernetes_provider.py
  • Base Class: Inherits from Provider (see base class details).
  • Purpose: Central orchestrator for Kubernetes-specific logic, session management, context and namespace discovery, credential validation, and configuration.
  • Key Kubernetes Responsibilities:
    • Initializes and manages Kubernetes sessions (supports kubeconfig file or content, context selection, and namespace scoping).
    • Validates credentials and sets up the Kubernetes identity context.
    • Loads and manages configuration, mutelist, and fixer settings.
    • Discovers accessible namespaces and cluster metadata.
    • Provides properties and methods for downstream Kubernetes service classes to access session, identity, and configuration data.

Data Models

  • Location: prowler/providers/kubernetes/models.py
  • Purpose: Define structured data for Kubernetes identity and session info.
  • Key Kubernetes Models:
    • KubernetesIdentityInfo: Holds Kubernetes identity metadata, such as context, cluster, and user.
    • KubernetesSession: Stores the Kubernetes API client and context information.

KubernetesService (Service Base Class)

  • Location: prowler/providers/kubernetes/lib/service/service.py
  • Purpose: Abstract base class that all Kubernetes service-specific classes inherit from. This implements the generic service pattern (described in service page) specifically for Kubernetes.
  • Key Kubernetes Responsibilities:
    • Receives a KubernetesProvider instance to access session, identity, and configuration.
    • Manages the Kubernetes API client and context.
    • Provides a __threading_call__ method to make API calls in parallel by resource.
    • Exposes common audit context (context, api_client, audit_config, fixer_config) to subclasses.

Exception Handling

Session and Utility Helpers

Specific Patterns in Kubernetes Services

The generic service pattern is described in service page. You can find all the currently implemented services in the following locations:

The best reference to understand how to implement a new service is following the service implementation documentation and taking other already implemented services as reference.

Kubernetes Service Common Patterns

  • Services communicate with Kubernetes using the Kubernetes Python SDK. See the official documentation.
  • Every Kubernetes service class inherits from KubernetesService, ensuring access to session, identity, configuration, and client utilities.
  • The constructor (__init__) always calls super().__init__ with the provider object, and initializes resource containers (typically as dictionaries keyed by resource UID or name).
  • Resource discovery and attribute collection can be parallelized using self.__threading_call__.
  • All Kubernetes resources are represented as Pydantic BaseModel classes, providing type safety and structured access to resource attributes.
  • Kubernetes API calls are wrapped in try/except blocks, always logging errors.
  • Additional attributes that cannot be retrieved from the default call should be collected and stored for each resource using dedicated methods and threading.

Specific Patterns in Kubernetes Checks

The Kubernetes checks pattern is described in checks page. You can find all the currently implemented checks in:

The best reference to understand how to implement a new check is following the Kubernetes check implementation documentation and taking other checks as reference.

Check Report Class

The Check_Report_Kubernetes class models a single finding for a Kubernetes resource in a check report. It is defined in prowler/lib/check/models.py and inherits from the generic Check_Report base class.

Purpose

Check_Report_Kubernetes extends the base report structure with Kubernetes-specific fields, enabling detailed tracking of the resource, name, and namespace associated with each finding.

Constructor and Attribute Population

When you instantiate Check_Report_Kubernetes, you must provide the check metadata and a resource object. The class will attempt to automatically populate its Kubernetes-specific attributes from the resource, using the following logic (in order of precedence):

  • resource_id:

    • Uses resource.uid if present.
    • Otherwise, uses resource.name if present.
    • Defaults to an empty string if none are available.

  • resource_name:

    • Uses resource.name if present.
    • Defaults to an empty string if not available.

  • namespace:

    • Uses resource.namespace if present.
    • Defaults to "cluster-wide" for cluster-scoped resources.

If the resource object does not contain the required attributes, you must set them manually in the check logic.

Other attributes are inherited from the Check_Report class, from which you always have to set the status and status_extended attributes in the check logic.

Example Usage

report = Check_Report_Kubernetes(
    metadata=check_metadata,
    resource=resource_object
)
report.status = "PASS"
report.status_extended = "Resource is compliant."