Skip to content

Kubernetes Discovery

Overview

Kubernetes Discovery enables automated identification and import of Kubernetes namespaces, pods, and containers into the PAM credential vault. This capability allows Kubernetes workloads to be represented as managed assets, enabling centralized credential management, access control, and session tracking for containerized environments. Discovery can be run repeatedly to keep the asset inventory current while preserving historical data and access records.

Configuration

To perform discovery and import from a Kubernetes deployment, a Kubernetes asset must be configured with the required connection and authentication information.

For instructions on creating this main Kubernetes asset, see Kubernetes Sessions. Kubernetes Discovery requires this asset to be configured before discovery can be initiated.

Authentication Requirements

  • Session Connectivity only: TLS certificates and a private key are sufficient.
  • Discovery and Import: An API token is required to access the Kubernetes API.

The Token field is included in the default Kubernetes asset type but is hidden by default. If Kubernetes Discovery is required, this field must be unhidden and populated with a valid API token.

Kubernetes Token Field


Trust Verification

Before running discovery, it is recommended to verify trust for the Kubernetes asset:

  • Navigate to Asset View > Manage > Verify Trust.
  • This step is particularly important when using self-signed certificates.
  • Verifying trust imports the Kubernetes API certificate into the 12Port keystore.

Kubernetes Trust Verification Button

Certificate Hostname Validation

By default, 12Port enforces hostname validation by matching the certificate’s hostname with the host defined in the Kubernetes asset record. If the certificate hostname does not match, one of the following approaches must be used:

  • Configure the Kubernetes asset host to match the certificate hostname and ensure it resolves via DNS or local host mapping.
  • Create a 12Port Alias (Configuration > Aliases) named Alias that maps the certificate hostname to the configured Kubernetes asset Host value. Aliases are not Kubernetes-specific and apply to all connection types.

Kubernetes Alias Configuration Example

Example: 12Port Alias mapping from Kubernetes source "minikube" to 12Port "pam.contoso.com"

  • Enable the Trust Certificate option on the asset to disable hostname verification.

Kubernetes Enable Trust Certificate Field

Example: Enable the "Trust Certificate" field.

Kubernetes Discovery Scripts

Kubernetes assets provide two discovery-related scripts, similar in behavior to discovery scripts used for Windows hosts.

Kubernetes Execute Script Menu Options


Script: Kubernetes Discover Containers

This script Kubernetes Discover Containers queries the Kubernetes API and only lists all discovered:

  • Namespaces
  • Pods
  • Containers

The results are displayed in the job output only. No assets or containers are created in the asset database. This script is intended for:

  • Validating connectivity and authentication
  • Reviewing Kubernetes topology
  • Performing a non-intrusive test run prior to import

Kubernetes Discovery Containers Script Results

Example: Output Result of "Kubernetes Discover Containers" Task Execution.


Script: Kubernetes Discover and Import Containers

This script Kubernetes Discover and Import Containers performs the same discovery process and additionally:

  • Generates discovery output for the discovered Kubernetes resources in raw CSV format, displayed in the Result field of the completed job (example shown in the screenshot below, highlighted in the red box).
  • Creates a corresponding container and asset hierarchy in the asset database (examples shown in the next "Imported Asset Database Hierarchy" section).

Imported objects are created in the same folder as the parent Kubernetes asset.

Kubernetes Discovery and Import Containers Script Results

Example: Output Result of "Kubernetes Discover and Import Containers" Task Execution.

Imported Asset Database Hierarchy

The import process creates the following structure:

  • A 12Port Container for each Kubernetes Namespace
    • A 12Port Container for each Pod within a Namespace
      • An Asset for each Kubernetes container within a Pod

Kubernetes Imported Namespace Container

Example: Kubernetes Imported "default" Namespace Container.

Kubernetes Imported Pod with Container

Example: Kubernetes Imported Pod Containing Imported Kubernetes Container.


In addition, the main Kubernetes asset is added as a Shadow Member to each imported container asset. This enables connectivity to each container using Shadow access, without additional asset configuration.

Kubernetes Imported Container with Shadow Member Association

Example: Imported Kubernetes Container with Shadow Member Association.

When launching a session, the Credential Type parameter in the Session Launcher must be set to the main Kubernetes asset (by name). This selection is required to retrieve the Kubernetes connection and authentication details necessary for successful session connectivity.

Kubernetes Imported Container Credential Type Session Connectivity

Example: Using the Session Launcher to Select the Shadow Member Asset by Name for Session Connectivity.

Rediscovery Behavior

The Kubernetes discovery and import process can be executed multiple times. Each run:

  • Preserves existing namespaces, pods, and containers
  • Adds newly discovered objects
  • Does not remove assets that no longer exist in the Kubernetes environment

Removed Kubernetes objects remain in the asset database to preserve associated configuration changes, session history, and audit events.