MinIO Operator certificate issued by Kubernetes CSR

In the current Kubernetes landscape, the standard approach for creating, managing, and automating TLS certificates is through the use of the kind: CertificateSigningRequest (CSR) resource. This native Kubernetes resource provides a robust and efficient way to handle the entire lifecycle of certificates within your cluster.

By leveraging the CSR resource, you can streamline and automate various aspects of certificate management, including:

1. Creating certificates: CSRs allow you to easily generate new certificates for your services, ensuring secure communication between components within your cluster.
2. Renewing certificates: With CSRs, you can automate the process of renewing certificates before they expire, eliminating the need for manual intervention and reducing the risk of service disruptions.
3. Revoking certificates: In case a certificate needs to be revoked due to security concerns or other reasons, CSRs provide a straightforward mechanism to invalidate the certificate and prevent its further use.

We will focus on utilizing the Kubernetes CSR resource specifically for creating a certificate that can be used by MinIO. By the end of this guide, you will have a clear understanding of how to generate a certificate using CSR, store it securely in a Kubernetes Secret, and configure MinIO to access and use the generated certificate.

The generated private keys and public certificates will be securely stored in a Kubernetes Secret named operator-tls. This Secret will be accessible to the Operators, allowing them to utilize the certificates for secure communication.

Tutorial

To start, we will generate a self-signed private key using the Elliptic Curve Digital Signature Algorithm (ECDSA) with the P-256 curve. ECDSA is a widely-used and secure algorithm for generating key pairs.

Step 1: Generate a Self-Signed Private Key

To start, we will generate a self-signed private key using the “Elliptic Curve Digital Signature Algorithm” (ECDSA) with the P-256 curve. ECDSA is a widely-used and secure algorithm for generating key pairs.

Optionally you could use a different algorithm, using RSA.

Step 2: Generate a Certificate Signing Request (CSR)

With the private key generated, we can now create a Certificate Signing Request (CSR). The CSR contains information about the entity requesting the certificate and is signed with the private key.

Step 3: Encode the CSR in Base64

To include the CSR in a Kubernetes resource, we need to convert it to a base64-encoded string.

Step 4: Create a Kubernetes CertificateSigningRequest

Create a file named csr-manual.yaml with the following contents, replacing <copy base64 encoded curve.csr here> with the base64-encoded CSR from the previous step.

Note: Regarding EKS 1.21 and 1.22: On EKS 1.22+ the signerName kubernetes.io/legacy-unknown is not allowed, you should set a signerName as in the example above or beta.eks.amazonaws.com/app-serving, for more details on CSR signing on EKS see Certificate signing documentation. On previous versions of EKS (1.21 and below) you could use the certificate CSR API v1beta1 and send the signerName kubernetes.io/legacy-unknown.

Note: on Kubernetes 1.21 and below: The field expirationSeconds was introduced in Kubernetes 1.22, prior to that the field is silently dropped and not honored

Using the csr-manual.yaml file created in the previous step, create the Kubernetes CSR resource.

Step 6: Approve the CSR

Approve the CSR manually. This is a one-time step.

Step 7: Retrieve the Signed Certificate

Get the public certificate from .status.certificate key in the Kubernetes csr resource.

Step 7: Verify the Certificate

Let’s verify the certificate we fetched above.

Extract the certificate from the CSR resource, it will be in base64. Decode the base64 and read it with OpenSSL as shown below.

A certificate description similar to this would appear:

The output will display the certificate details, including the subject, issuer, validity period, and extensions.

Step 9: Create a Kubernetes Secret

Finally, this is where the rubber meets the road. We’ll create a Kubernetes secret for Operator to use

Next time the operator starts, it will not attempt to create the certificate or the secret, instead it will be using the one we stored in the secret minio-operator.

Simplifying Certificate Management with MinIO and Kubernetes

We couldn’t have written this short tutorial with another object store. Other similar object stores are tremendously complex and time consuming to set up, but we just set up the MinIO operator to use certificates from a secret without too much lift by just using built-in Kubernetes resources.

While other object storage solutions often require complex configurations and time-consuming setup processes, MinIO's design and tight integration with Kubernetes allow developers and administrators to focus on their core business logic, knowing that their object storage is secure and properly authenticated. The simplicity and efficiency of MinIO's certificate management process set it apart from the competition, making it the preferred choice for businesses seeking a powerful and reliable object storage solution.

If you have any questions, encounter challenges, or simply want to share your experiences with MinIO, our vibrant community is here to help. Join us on Slack, where you can connect with fellow MinIO enthusiasts, get expert advice, and stay up-to-date with the latest developments in the world of object storage.