diff --git a/.github/markdownlint/.markdownlint-cli2.yaml b/.github/markdownlint/.markdownlint-cli2.yaml index 2d3ef15f0..563e6fbeb 100644 --- a/.github/markdownlint/.markdownlint-cli2.yaml +++ b/.github/markdownlint/.markdownlint-cli2.yaml @@ -595,6 +595,22 @@ config: example_from: "These vendors try to gyp customers." example_to: "These vendors try to cheat customers." + # ML-KEM algorithm naming (NIST FIPS 203) + - term: "MLKEM-768" + replacement: "ML-KEM 768" + example_from: "X25519 + MLKEM-768" + example_to: "X25519 + ML-KEM 768" + + - term: "ML-KEM768" + replacement: "ML-KEM 768" + example_from: "ML-KEM768 (NIST PQC KEM)" + example_to: "ML-KEM 768 (NIST PQC KEM)" + + - term: "ML-KEM-768" + replacement: "ML-KEM 768" + example_from: "ML-KEM-768 key exchange" + example_to: "ML-KEM 768 key exchange" + # AKY018: Require canonical Markdown table separator rows # # Purpose: diff --git a/.gitleaks.toml b/.gitleaks.toml new file mode 100644 index 000000000..a66340692 --- /dev/null +++ b/.gitleaks.toml @@ -0,0 +1,27 @@ +title = "Gitleaks Configuration — technical-documentation" + +# --------------------------------------------------------------------------- +# Global allowlist +# --------------------------------------------------------------------------- +# These entries exempt specific files that contain intentional examples or +# documentation content, not real credentials. +# --------------------------------------------------------------------------- + +[allowlist] + description = "False-positive allowlist for files containing intentional credential-like examples" + + # .github/LEAK_RESPONSE.md — secret-leak response runbook. + # Contains an intentional JWT header example + # (`eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...REDACTED`) used to illustrate + # how to redact JWT tokens in documentation. This is a documentation + # artifact, not a real credential. + # + # .github/markdownlint/custom-rules.js — AKY023 custom lint rule. + # Contains the string `DATABASE_PASSWORD=hardcoded123` only in a JSDoc + # comment that documents what the rule is designed to detect. This is a + # rule-description example, not a real credential. + + paths = [ + '''\.github/LEAK_RESPONSE\.md''', + '''\.github/markdownlint/custom-rules\.js''', + ] diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml index 7e525a559..dca2261cd 100644 --- a/.pre-commit-config.yaml +++ b/.pre-commit-config.yaml @@ -4,7 +4,7 @@ repos: hooks: - id: gitleaks name: gitleaks (secret scan) - args: ["protect", "--staged", "--redact"] + args: ["--staged", "--redact"] # Local hooks: markdownlint, cspell, lychee # Note: These run sequentially on edited markdown files. Markdownlint uses --fix to auto-correct issues. diff --git a/docs/Akeyless Gateway/configure-gateway/_order.yaml b/docs/Akeyless Gateway/configure-gateway/_order.yaml index 02a838f30..f9208e384 100644 --- a/docs/Akeyless Gateway/configure-gateway/_order.yaml +++ b/docs/Akeyless Gateway/configure-gateway/_order.yaml @@ -1,5 +1,6 @@ - gateway-authentication-and-access - gateway-tls-settings +- gateway-pqc-support-reference - gateway-certificate-store - gateway-zero-knowledge - gateway-caching diff --git a/docs/Akeyless Gateway/configure-gateway/gateway-pqc-support-reference.md b/docs/Akeyless Gateway/configure-gateway/gateway-pqc-support-reference.md new file mode 100644 index 000000000..aa351d1a3 --- /dev/null +++ b/docs/Akeyless Gateway/configure-gateway/gateway-pqc-support-reference.md @@ -0,0 +1,100 @@ +--- +title: PQC Support Reference +excerpt: Hybrid PQC profile and coverage details for Akeyless SaaS and Gateway +deprecated: false +hidden: false +metadata: + title: 'PQC Support Reference | Akeyless' + description: 'Hybrid post-quantum cryptography (PQC) profile, coverage matrix, and verification guidance for Akeyless SaaS and Gateway TLS connections.' + robots: index +next: + description: '' +--- +Akeyless implements hybrid post-quantum cryptography (PQC) for TLS connections between clients and both the Akeyless SaaS platform and Akeyless Gateway deployments. This page provides the cryptographic profile, coverage matrix, and verification steps for compliance and operational reference. + +## Cryptography Profile + +Akeyless TLS hybrid PQC connections use the following profile: + +| Parameter | Value | +| --- | --- | +| TLS version | `TLS 1.3` | +| Hybrid key exchange identifier | `X25519MLKEM768` | +| Classical component | X25519 | +| Post-quantum component | ML-KEM 768 (NIST FIPS 203) | + +`X25519MLKEM768` indicates a hybrid key exchange where both classical and post-quantum algorithms participate in the TLS handshake. + +## Coverage and Configuration Matrix + +| Connection path | Hybrid PQC support | Required action | +| --- | --- | --- | +| Client to Akeyless SaaS | Enabled by default | No user configuration required | +| Client to Akeyless Gateway endpoint | Supported, configuration required | Set `MIN_TLS_VERSION=TLSv1.3` on the Gateway deployment | +| Gateway to Akeyless SaaS | Enabled by default | No user configuration required | + +## Gateway Configuration Requirements + +To enable hybrid PQC for the Akeyless Gateway endpoint, set the following environment variable in the deployment: + +* `MIN_TLS_VERSION=TLSv1.3` + +When TLS 1.3 is enabled, the Go runtime negotiates `X25519MLKEM768` automatically. No additional flags are required. + +After changing `MIN_TLS_VERSION`, restart or redeploy the Gateway so the updated value is applied. + +Deployment examples: + +* [Gateway Docker Advanced Configuration](https://docs.akeyless.io/docs/gateway-docker-advanced-configuration) +* [Gateway Kubernetes Helm Values Reference](https://docs.akeyless.io/docs/gateway-kubernetes-helm-values-reference) + +## Client Compatibility + +Hybrid PQC key exchange requires both peers to support `X25519MLKEM768`. The following clients negotiate it automatically: + +* Current major browsers +* Go runtime 1.24 and later (including the Akeyless Go SDK and CLI) + +Older clients that do not support `X25519MLKEM768` fall back to a classical key exchange without disrupting the TLS connection. + +## Verification Guidance + +To verify hybrid PQC on a Gateway endpoint using a browser: + +1. Open the Gateway endpoint over HTTPS in a browser. +2. Open the browser connection security details. +3. Confirm the negotiated key exchange includes `X25519MLKEM768`. + +To verify using OpenSSL (requires OpenSSL 3.5.0 or later): + +```shell Linux and macOS +openssl s_client -connect : -tls1_3 2>&1 | grep "Server Temp Key" +``` +```powershell Windows +openssl s_client -connect : -tls1_3 2>&1 | Select-String "Server Temp Key" +``` + +A hybrid PQC key exchange returns output similar to: + +```text +Server Temp Key: X25519MLKEM768 +``` + +Interpretation: + +* `Server Temp Key: X25519MLKEM768`: Hybrid PQC is active. +* `Server Temp Key: X25519`: The connection negotiated classical key exchange. + +If you expect hybrid PQC but observe `X25519`, confirm that the client supports `X25519MLKEM768` and that the Gateway is configured with `MIN_TLS_VERSION=TLSv1.3`. + +Troubleshooting checklist: + +* Confirm the command is targeting the Gateway endpoint directly. +* Confirm the Gateway has restarted after applying `MIN_TLS_VERSION=TLSv1.3`. +* Confirm the client and OpenSSL version support `X25519MLKEM768`. + +## Related Resources + +* [TLS Settings](https://docs.akeyless.io/docs/gateway-tls-settings) +* [FIPS Certifications](https://docs.akeyless.io/docs/fips) +* [Akeyless Blog: Akeyless Advances Security with Post-Quantum Hybrid TLS 1.3](https://www.akeyless.io/blog/post-quantum-akeyless-hybrid-tls-1-3/) diff --git a/docs/Akeyless Gateway/configure-gateway/gateway-tls-settings.md b/docs/Akeyless Gateway/configure-gateway/gateway-tls-settings.md index b93f67c98..fef5a412b 100644 --- a/docs/Akeyless Gateway/configure-gateway/gateway-tls-settings.md +++ b/docs/Akeyless Gateway/configure-gateway/gateway-tls-settings.md @@ -32,14 +32,16 @@ To configure TLS, on your [Gateway Configuration Manager](https://docs.akeyless. ## TLS 1.3 and PQC -To enable hybrid post-quantum key exchange on the Gateway, configure the deployment to use TLS 1.3. +For Akeyless SaaS endpoints, hybrid post-quantum key exchange is enabled by default over TLS 1.3. + +For Akeyless Gateway endpoints, hybrid post-quantum key exchange is enabled when the Gateway is configured to use TLS 1.3. For deployment-specific steps, see: * [Gateway Docker Advanced Configuration](https://docs.akeyless.io/docs/gateway-docker-advanced-configuration) * [Gateway Kubernetes Helm Values Reference](https://docs.akeyless.io/docs/gateway-kubernetes-helm-values-reference) -After deployment, verify that the browser connection details show `X25519MLKEM768`, which confirms a hybrid key exchange (`X25519` + `MLKEM-768`). +After deployment, verify that the browser connection details show `X25519MLKEM768`, which confirms a hybrid key exchange (X25519 + ML-KEM 768). ## Updating a TLS Certificate diff --git a/docs/Akeyless Gateway/configure-gateway/index.md b/docs/Akeyless Gateway/configure-gateway/index.md index 33e1022c6..94cdab3bc 100644 --- a/docs/Akeyless Gateway/configure-gateway/index.md +++ b/docs/Akeyless Gateway/configure-gateway/index.md @@ -38,6 +38,8 @@ The following configuration features are available: * Configure HTTPS behavior and certificate usage in [TLS Settings](https://docs.akeyless.io/docs/gateway-tls-settings). +* Review cryptography profile and coverage details in [PQC Support Reference](https://docs.akeyless.io/docs/gateway-pqc-support-reference). + * Manage trusted private CAs in [Certificate Store](https://docs.akeyless.io/docs/gateway-certificate-store). * Configure encryption posture with customer fragments in [Zero Knowledge](https://docs.akeyless.io/docs/gateway-zero-knowledge). diff --git a/docs/Akeyless Gateway/deploy-gateway/gateway-deploy-kubernetes-helm/gateway-kubernetes-helm-values-reference.md b/docs/Akeyless Gateway/deploy-gateway/gateway-deploy-kubernetes-helm/gateway-kubernetes-helm-values-reference.md index eeb27fad2..0a9c264a7 100644 --- a/docs/Akeyless Gateway/deploy-gateway/gateway-deploy-kubernetes-helm/gateway-kubernetes-helm-values-reference.md +++ b/docs/Akeyless Gateway/deploy-gateway/gateway-deploy-kubernetes-helm/gateway-kubernetes-helm-values-reference.md @@ -117,27 +117,22 @@ Alternatively, you can also [configure TLS](https://docs.akeyless.io/docs/gatewa The same TLS and PQC settings apply across all cloud platforms where Akeyless Gateway runs on Kubernetes, including managed and self-managed clusters. -To enable hybrid post-quantum key exchange on the Gateway pod, set TLS 1.3 and add the Go runtime flag in `globalConfig.env`: +To enable hybrid post-quantum key exchange on the Gateway pod, set TLS 1.3 in `TLSConf`: ```yaml values.yaml TLSConf: enabled: true minimumTlsVersion: TLSv1.3 - -globalConfig: - env: - - name: GODEBUG - value: tlsmlkem=1 ``` -Apply the updated chart values and restart/upgrade the Gateway release so the pod loads the new runtime flag. +Apply the updated chart values and restart/upgrade the Gateway release. To verify PQC support, open the Gateway endpoint over HTTPS in Chrome, check the connection security details, and confirm the negotiated key exchange includes `X25519MLKEM768`. `X25519MLKEM768` confirms a hybrid key exchange: * `X25519` (classical elliptic-curve cryptography) -* `MLKEM-768` (post-quantum cryptography) +* ML-KEM 768 (post-quantum cryptography) ### OIDC Configuration diff --git a/docs/Akeyless Gateway/deploy-gateway/gateway-deploy-standalone-docker/gateway-docker-advanced-configuration.md b/docs/Akeyless Gateway/deploy-gateway/gateway-deploy-standalone-docker/gateway-docker-advanced-configuration.md index b9ece1fbe..bf55ecf8d 100644 --- a/docs/Akeyless Gateway/deploy-gateway/gateway-deploy-standalone-docker/gateway-docker-advanced-configuration.md +++ b/docs/Akeyless Gateway/deploy-gateway/gateway-deploy-standalone-docker/gateway-docker-advanced-configuration.md @@ -329,29 +329,28 @@ After TLS is configured and the Gateway is available over HTTPS, validate the ne `X25519MLKEM768` confirms a hybrid key exchange: * `X25519` (classical elliptic-curve cryptography) -* `MLKEM-768` (post-quantum cryptography) +* ML-KEM 768 (post-quantum cryptography) This confirms the connection is using **TLS 1.3 with hybrid post-quantum key exchange**. #### Gateway Restart Requirement -To enable PQC support, restart the Gateway with the required environment variables: +To enable hybrid PQC support on the Gateway endpoint, restart the Gateway with the required environment variable: ```shell docker run -d \ -p 8000:8000 \ -p 5696:5696 \ -e MIN_TLS_VERSION=TLSv1.3 \ --e GODEBUG=tlsmlkem=1 \ --name akeyless-gateway \ akeyless/base:latest-akeyless ``` -The variables `MIN_TLS_VERSION=TLSv1.3` and `GODEBUG=tlsmlkem=1` enable hybrid PQC support (`X25519 + MLKEM-768`) on the Gateway container. +Setting `MIN_TLS_VERSION=TLSv1.3` enables hybrid PQC support (X25519 + ML-KEM 768) on the Gateway container. -> 📘 Info +> ℹ️ **Info:** > -> Hybrid PQC support is validated at the Gateway endpoint level. Data in transit between the Gateway and Akeyless SaaS is already encrypted. +> Akeyless SaaS connections already use hybrid PQC encryption by default over TLS 1.3. The environment variables in this section are required for the Gateway endpoint configuration. ### Cache Configuration diff --git a/docs/Getting Started/dfc-overview/dfc-deep-dive.md b/docs/Getting Started/dfc-overview/dfc-deep-dive.md index 686c5c036..0472f291d 100644 --- a/docs/Getting Started/dfc-overview/dfc-deep-dive.md +++ b/docs/Getting Started/dfc-overview/dfc-deep-dive.md @@ -16,7 +16,7 @@ DFC uses standard, NIST-approved primitives: * **AES** — symmetric encryption * **HMAC** — message authentication and integrity * **KDFs** — for deriving per-operation values from fragments -* **Hybrid TLS 1.3 (ML-KEM768 + X25519)** — post-quantum–resistant communication +* **Hybrid TLS 1.3 (ML-KEM 768 + X25519)** — post-quantum–resistant communication DFC does not introduce new encryption algorithms; it introduces a new key-handling and fragmentation model. @@ -199,7 +199,7 @@ DFC enables a zero-knowledge model: DFC uses hybrid TLS 1.3 with: -* **ML-KEM768** (NIST PQC KEM) +* **ML-KEM 768** (NIST PQC KEM) * **X25519** (classical elliptic curve) These provide protection against potential future quantum attacks on captured traffic.