Add a Kubernetes Cluster

Last modified on September 7, 2022

This guide describes how to manage access to a Kubernetes cluster via the strongDM Admin UI. This process involves creating and configuring a new cluster in the Admin UI and checking the connection to your Kubernetes API server.

Prerequisites

Ensure that the Kubernetes API server that you are adding to strongDM is accessible from your strongDM gateways or relays. See our guide on Gateways for more information.

Steps

  1. Log in to the Admin UI and go to Infrastructure > Clusters.

  2. Click the Add cluster button.

  3. Specify the cluster settings:

    Kubernetes Setup
    Kubernetes Setup
    1. Display Name (Required): Enter a meaningful name for this resource, such as k8s-sandbox. This name displays throughout strongDM. Do not include special characters like quotes (") or angle brackets (< or >).

    2. Cluster Type (Required): Select Kubernetes.

    3. Hostname (Required): Enter the hostname or IP address of the Kubernetes API server, such as api.kubernetes.example.com.

    4. Port (Required): Enter the port (default: 443) to connect to the API server.

    5. Port Override: After this resource is created, this field is automatically filled with a port between 1024-59999 that is not in use by another resource. You can optionally overwrite it with your own preferred port later in the Port Overrides settings. Note that after specifying the port override number, you must also update the kubectl configuration. See section Port Overrides for more information.

    6. Secret Store: If a Secret Store integration is configured, select where the credentials for this cluster are stored.

    7. Server CA (Required): Paste the server certificate (plaintext or Base64-encoded), or import a PEM file. You can either generate the server certificate on the API server or get it in Base64 format from your existing Kubernetes configuration (kubeconfig) file.

      To get the server CA from your kubeconfig file:

      1. Open the CLI and type cat ~/.kube/config to view the contents of the file.

      2. In the file, under - cluster, copy the certificate-authority-data value. That is the server certificate in Base64 encoding.

          - cluster:
          certificate-authority-data: ... SERVER CERT BASE64 ...
        
    8. Client Certificate (Required): Paste the client certificate (plaintext or Base64-encoded), or import a .PEM file. You can either generate the client certificate on the API server or get it in Base64 format from your kubeconfig file.

      To get the client certificate from your kubeconfig file:

      1. From the CLI, type cat ~/.kube/config to view the contents of the file.

      2. In the file, under - name, copy the client-certificate-data value. That is the client certificate in Base64 encoding.

          - name: clusterUser_StrongDM_example
          user:
          client-certificate-data: ... CLIENT CERT BASE64...
        
    9. Client Key (Required): Paste the client private key (plaintext or Base64-encoded), or import a .PEM file. You can either generate the client private key on the API server or get it in Base64 format from your kubeconfig file.

      To get the client private key from your kubeconfig file:

      1. Open the CLI and type cat ~/.kube/config to view the file.

      2. In the file, under - name, copy the client-key-data value. That is the client private key in Base64 encoding.

          - name: clusterUser_StrongDM_example
          user:
          client-key-data: ... CLIENT PRIVATE KEY BASE64...
        
    10. Healthcheck Namespace (Required): If enabled for your organization, this field allows you to specify the namespace used for the resource healthcheck. The supplied credentials must have the rights to perform one of the following kubectl commands in the specified namespace: get pods, get deployments, or describe. If not specified, the namespace is set to default.

    11. Authentication (Required): Select either Leased Credential (the default model to access the cluster) or Remote Identities (to use the Remote Identities of strongDM users to access the cluster).

    12. Healthcheck Username (Required): If Authentication is set to Remote Identities, enter the username that should be used to verify strongDM’s connection to it. Note that the username must already exist on the target cluster.

    13. Resource Tags (Optional): Assign tags to the resource by entering key-value pairs in the format <KEY>=<VALUE>, such as env=dev.

The Admin UI updates and shows your new server in a green or yellow state. Green indicates a successful connection. If it is yellow, click the pencil icon to the right of the server to reopen the Connection Details screen. Then click Diagnostics to determine where the connection is failing.

If any errors occur, please copy them into an email and send them to support@strongdm.com.

Top