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 and How to sign a 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:

      • Secret: the name of the secret.
      • Namespace: the namespace of the secret.

      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.

   2. In the Automatic redeploy table, add the resources to redeploy after the secrets are updated. For each row, enter:

      • Type: select Deployment, StatefulSet, or DaemonSet.
      • Name: the name of the resource.
      • Namespace: the namespace of the resource.

      Segura® redeploys each resource by updating the redeploytimestamp label in spec.template.metadata.labels.

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.

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>, …

<route> is via Network Connector <agent> (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.