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

# Kubernetes cert-manager

> Conceptual introduction to integrating Kubernetes cert-manager with CryptoHub via API and Futurex controller.

This document provides information on integrating Kubernetes `cert-manager` with CryptoHub through CryptoHub's API and Futurex's issuer controller.

## About Kubernetes

According to [**Kubernetes overview**](https://kubernetes.io/docs/concepts/overview/):

<Paragraph indent="1">
  "Kubernetes is a portable, extensible, open source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. It has a large, rapidly growing ecosystem. Kubernetes services, support, and tools are widely available."
</Paragraph>

<Note>
  For a detailed review of the Kubernetes (K8s) components and structure, refer to the offical

  [Kubernetes documentation](https://kubernetes.io/docs/home/).
</Note>

## What is CryptoHub?

Futurex's CryptoHub is the most flexible and versatile cryptographic platform in the industry, combining every cryptographic function within Futurex’s extensive solution suite. It enables organizations to deploy, manage, and monitor virtual cryptographic modules — including HSM emulators, certificate authorities (CAs), key generation services, and PKI workflows — all through a unified web-based dashboard.

CryptoHub can be operated via its intuitive GUI to:

* Issue and revoke X.509 certificates
* Manage root and intermediate CAs
* Enforce key usage policies (e.g., Sign/Verify, Key Encipherment)
* Integrate with external systems (e.g., Kubernetes, PKI APIs, CI/CD pipelines)

## What is Kubernetes cert-manager?

`cert-manager` is a popular native Kubernetes tool designed to automate the management and issuance of TLS (Transport Layer Security) certificates within the cluster. It ensures that certificates are valid and up-to-date, and attempts to renew them at a configured time before expiration.

In a Kubernetes environment, applications often need TLS certificates to secure communication, such as between microservices or for inbound/outbound traffic. Manually managing these certificates across many services can be complex and error-prone.

`cert-manager` simplifies this by:

* **Issuing Certificates:** It can acquire certificates from various sources, known as Issuers or ClusterIssuers (like Futurex CryptoHub in this guide), including self-signed CAs, and external CAs.
* **Managing the Lifecycle:** It automatically handles the certificate signing request (CSR) process and stores the resulting certificate and private key in a standard Kubernetes object called a `Secret`. A Kubernetes `Secret` is an object that stores sensitive data such as password, OAuth tokens, or APIs keys.
* **Automating Renewal:** It monitors issued certificates and triggers a renewal request automatically before they expire, ensuring uninterrupted secure service.

`cert-manager` provides the native Kubernetes API and control loop that allows users to request certificates using standard Kubernetes manifests (YAML), abstracting away the specifics of the actual CA that performs the signing.

## How CryptoHub works with Kubernetes

In this deployment, Kubernetes serves as the **orchestration layer** for critical security and certificate management services. The integration follows this workflow:

1. An application team creates a `Certificate` resource in Kubernetes (YAML) requesting a TLS certificate (e.g., **example.com**).
2. `cert-manager` detects the request and creates a `CertificateRequest` resource.
3. Futurex's `issuer-controller` receives the request and sends it to CryptoHub through its REST API.
4. CryptoHub registers the request as **pending approval**.
5. An authorized approver logs into CryptoHub, reviews request details (issuer, subject, validity, purpose), and manually **approves** or **denies** the request.
6. If **approved,** CryptoHub signs the certificate and returns it to the controller.
7. The controller then stores the **signed certificate** in a **Kubernetes**`Secret`.
8. The application pod mounts the `Secret` and uses the certificate for **TLS**.

## Why this design matters

This architecture emphasizes **security** and **control**. By separating **automation** (via Kubernetes) from **authorization** (via CryptoHub’s GUI), every certificate undergoes human review before issuance — satisfying enterprise security policies, audit requirements, and zero-trust principles.