---
title: "Configure Kubernetes"
slug: "clm-configure-kubernetes"
updated: 2026-11-06T16:50:17Z
published: 2026-11-06T16:50:17Z
canonical: "docs.senhasegura.io/clm-configure-kubernetes"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://docs.senhasegura.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Configure Kubernetes

This document provides information on how to configure the Kubernetes publishing profile to make it possible to install and publish certificates on cluster resources.

## Requirements

- A certificate generated and signed by a CA. More information in [How to create a request](/v4-2/docs/certificates-flow-how-to-requisitions) and [How to sign a request](/v4-2/docs/certificates-flow-how-to-sign-request). The certificate must have a private key.
- A Kubernetes cluster registered as a device in Segura®.
- An HTTPS connectivity on the device, set to the port of the Kubernetes API (for example, `6443`). Without it, the publication fails with the error `Equipment without HTTPS connectivity`.
- An access credential whose password is the bearer token of a Kubernetes ServiceAccount. The ServiceAccount needs RBAC permission to `patch` secrets and the deployments, statefulsets, and daemonsets you redeploy.

## Configure Kubernetes

To configure Kubernetes, see the following steps:

1. On Segura®, in the navigation bar, hover over the **Products** menu and select **Certificate Manager**.
2. In the side menu, select **Publishing** > **Publishing profiles**.
3. In the actions button, select **Kubernetes**.
4. In the **Settings** tab, enter the following information:
  1. In the **Profile name ***, enter the profile's name.
  2. In the **Credential username**, enter the credentials' name.
  3. Optional: Check the **Use a registered credential to access all devices** option and, in the **Access credential registered in the system**, select the access credential registered in Segura® to be used.
5. Click **Continue**.
6. In the **Kubernetes** tab, fill in the following tables. You can add several rows to each table.
  1. In the **Secrets** table, add the secrets that store the certificate. For each row, enter:

Each secret must already exist and contain the `tls.crt` and `tls.key` keys, as in a secret of type `kubernetes.io/tls`. Segura® replaces the values of these two keys and does not create the secret.
    - **Secret**: the name of the secret.
    - **Namespace**: the namespace of the secret.
  2. In the **Automatic redeploy** table, add the resources to redeploy after the secrets are updated. For each row, enter:

Segura® redeploys each resource by updating the `redeploytimestamp` label in `spec.template.metadata.labels`.
    - **Type**: select **Deployment**, **StatefulSet**, or **DaemonSet**.
    - **Name**: the name of the resource.
    - **Namespace**: the namespace of the resource.
7. Click **Continue**.
8. In the **Devices** tab, select the Kubernetes cluster.
  1. The device must be previously registered in Segura®.
9. In the **Review** tab, review all information entered previously, and click **Save**.

Info

The **Devices** and **Review** tabs show a read-only **Network Connector** column with **Yes** or **No**, depending on whether the device has its own Network Connector agent configured.

## Verify your results

After publishing a certificate to Kubernetes, check the execution log to confirm the result.

The log identifies which Network Connector the publication used to reach the cluster.

If the secret or the resource redeploy is not updated, the execution ends in **Error**.

If Segura® cannot connect to the Kubernetes API, the execution fails with the following message. The connection times out after 10 seconds, and the whole request after 60 seconds.

```
Unable to reach the Kubernetes API at <ip>:<port> (<route>): <connection error>
```

If the Kubernetes API responds with an error, the execution fails with one of the following messages:

```
Kubernetes publishing failed for <N> secret(s): <namespace/name>, …
Kubernetes redeploy failed for <N> resource(s): <namespace/type/name>, …
```

`&lt;route&gt;` is **via Network Connector `&lt;agent&gt;`** (the device's own agent, or, if the device has none, the default Network Connector) or **direct connection**. If a secret update fails, the redeploy does not run. The error column in Publishing status truncates the message to about 255 characters; the execution log shows the full text.

The log lines recorded before the failure are kept; they are not removed.

Clusters behind a proxy or a load balancer that routes by hostname, such as Rancher or a cloud load balancer, connect through the Network Connector, because Segura® keeps the cluster hostname for SNI and the `Host` header.