Installer Certificate TTL (Conjurer)

Installer Certificate TTL (Conjurer) - Coming Soon

The proposed feature introduces an advanced approach to managing Conjurer certificates within a Managed Kubernetes Service (MKS) environment. By default, the Time-to-Live (TTL) for these certificates is set to 365 days, replacing the previous 100-year expiration period with a more dynamic solution. Users can customize this TTL during cluster configuration, with options ranging from 1 day to an indefinite period. For instance, setting the TTL to 1 day will cause the certificate to expire after 1 day, making the nodes inoperable until renewed during Day-2 operations.

By allowing users to customize the Time-to-Live (TTL) for Conjurer certificates, they can ensure that certificates are renewed at intervals that align with their security policies. This reduces the risk of long-lived certificates, which can become a security vulnerability. Additionally, the ability to set shorter TTLs helps in enforcing regular updates, ensuring that security credentials remain current and minimizing the window of exposure to potential threats.

Users will utilize the Conjurer certificate management feature in the following scenarios:

During Cluster Configuration: When setting up a Managed Kubernetes Service (MKS) cluster, users can specify the Time-to-Live (TTL) for Conjurer certificates. This allows them to tailor certificate expiration to their security policies and operational needs right from the start. Configure shorter TTLs to ensure that certificates are rotated regularly, thereby enhancing security and compliance.
For Day-2 Operations: When performing ongoing maintenance or adding new nodes, users can leverage the manual certificate rotation features to ensure that certificates remain up-to-date, minimizing downtime and ensuring continued node operability.

Did you know ?

Installer Certificate TTL can be managed through various methods:

Cluster Configuration via UI¶

Day-0 Operation¶

During a new cluster configuration via UI, enter the required days of expiry for the conjurer certificate. This certificate is generated for the initial authentication and node approval process.

Day-2 Operation¶

Users can utilize the Day-2 operation to renew the TTL configuration for the Conjurer certificate if they need to adjust its expiration settings after deployment. This option is beneficial for updating security policies, meeting compliance requirements, or managing certificates dynamically. If users prefer not to use the initially set 100-year expiry, they can update the certificate’s TTL through the cluster configuration page during this Day 2 operation.

Enter the required number of day and click Update

Advanced Settings

Cluster Configuration via RCTL¶

Day-0 Operation¶

The Installer TTL configuration can be set in the MKS Cluster Config Spec. Below is an example of the config spec:

apiVersion: infra.k8smgmt.io/v3
kind: Cluster
metadata:
  name: demo-mkscluster
  project: defaultproject
spec:
  blueprint:
    name: minimal
  config:
    autoApproveNodes: true
    installerTtl: 57
    kubernetesVersion: v1.29.4
    network:
      cni:
        name: Calico
        version: 3.26.1
      podSubnet: 10.244.0.0/16
      serviceSubnet: 10.96.0.0/12
    nodes:
    - arch: amd64
      hostname: demo-m5
      operatingSystem: Ubuntu20.04
      privateip: 10.0.0.40
      roles:
      - Worker
      - Master
    proxy: {}
  proxyconfig: {}
  type: mks

Day-2 Operation¶

To renew the Installer TTL after cluster deployment, users can update the existing cluster config spec by adding or modifying the parameter installerTtl. This parameter must be set to a numeric value representing the number of days.

For example: installerTtl: 20 sets the certificate's validity period to 20 days. This value dictates how long the certificate remains valid before it needs renewal, allowing users to manage certificate lifecycles according to their security policies or operational requirements.

In a scenario where the TTL value specified by the user during cluster provisioning (Day 0) is the same as the value they want to apply during Day 2 configuration updates, the configuration will not be applied. This is because the values given earlier and now are the same, and there will be no change to the configuration to be applied.

In such cases, users can use the rctl imperative command to renew the TTL using the following command:

```bash ./rctl create installer-cert-configure --installer-ttl