diff --git a/modules/get-started/pages/whats-new.adoc b/modules/get-started/pages/whats-new.adoc index 4d18818c2b..07b32b7598 100644 --- a/modules/get-started/pages/whats-new.adoc +++ b/modules/get-started/pages/whats-new.adoc @@ -49,7 +49,17 @@ This release includes several updates to xref:get-started:licensing/overview.ado - *30-day trial Enterprise license*: Starting with version 24.3, new Redpanda clusters automatically receive a trial license that's valid for 30 days, allowing unrestricted use of Enterprise features. This evaluation period begins when the cluster is created for the first time. After this period expires, inactive Enterprise features are disabled, and active features enter a restricted state. -== Declarative user and ACL management in Kubernetes +== PKCS#12 support for TLS listeners + +Redpanda now supports configuring TLS using PKCS#12 files, which allows you to manage both the certificate and private key in a single, password-protected file. + +For more details, see xref:manage:security/encryption.adoc[]. + +This feature is not yet available in Kubernetes deployments that use the Redpanda Helm chart or the Redpanda Operator. + +== New features in the Redpanda Operator + +=== Declarative user and ACL management The Redpanda Operator now supports declarative management of users and access control lists (ACLs) using the new User custom resource, starting in version v2.2.2-24.2.4. This feature allows you to: @@ -59,7 +69,7 @@ The Redpanda Operator now supports declarative management of users and access co To learn more, see the xref:manage:kubernetes/security/authentication/k-user-controller.adoc[User custom resource documentation]. -== Declarative schema management in Kubernetes +=== Declarative schema management The Redpanda Operator now supports declarative schema management using the Schema custom resource, starting in version v2.3.0-24.3.1. This feature allows you to: @@ -69,7 +79,7 @@ The Redpanda Operator now supports declarative schema management using the Schem To learn more, see the xref:manage:kubernetes/k-schema-controller.adoc[Schema custom resource documentation]. -== Use Redpanda Operator without Flux +=== Use Redpanda Operator without Flux The Redpanda Operator now supports the `useFlux` flag, giving you control over resource management, starting in version v2.3.0-24.3.1: diff --git a/modules/manage/pages/security/encryption.adoc b/modules/manage/pages/security/encryption.adoc index 7459dc6f6f..d9b26378dd 100644 --- a/modules/manage/pages/security/encryption.adoc +++ b/modules/manage/pages/security/encryption.adoc @@ -10,39 +10,57 @@ By default, Redpanda data is sent unencrypted. A security best practice is to en * Transport Layer Security (TLS), previously SSL, provides encryption for client-server communication. A server certificate prevents third parties from accessing data transferred between the client and server. By default, Redpanda clusters accept connections from clients using TLS version 1.2 or later, but <>. * mTLS, or 2-way TLS, is a protocol that authenticates both the server and the client. In addition to the server certificate required in TLS, mTLS also requires the client to give a certificate. This involves more overhead to implement, but it can be useful for environments that require additional security and only have a small number of verified clients. -For each Redpanda broker, you must specify the: +== Prerequisites -* key file (`broker.key`) -* certificate file (`broker.crt`) -* truststore file (`ca.crt`). +TLS certificates are required for encryption. You can use your own certificates, either self-signed or issued by a trusted CA. -Each broker has its own `broker.key` and `broker.crt`, but all brokers can have the same `ca.crt`. +You'll need the following files: +-- +- A private key file (`broker.key`) for each broker. +- A certificate file (`broker.crt`) for each broker. +- A truststore file (`ca.crt`). All brokers can have the same `ca.crt` file. +-- -If you enable TLS encryption, you can also specify a certificate revocation list (`ca.crl`) so that Redpanda can check and reject connections from entities using certificates already revoked by a certificate authority (CA). All brokers can have the same `ca.crl`. The file must contain a single, concatenated list of certificate revocation lists (CRLs) for all issuing certificates in the truststore file. +Ensure these files are readable by Redpanda and protected against unauthorized access: -== Prerequisites +[,bash] +---- +chmod 400 broker.key broker.crt ca.crt +chown redpanda:redpanda broker.key broker.crt ca.crt +---- -TLS certificates are necessary for encryption. You can use your own certificates, either self-signed or issued by a trusted CA. +For mTLS, client certificates signed by the same CA are also required. -=== Create a local CA for self-signed certificates +If you don't already have these files, you can learn how to generate them in <>. -NOTE: This step is required if you want to generate multiple certificates all signed by -the same root; for example, you want to use mTLS but issue different certificates -to multiple Redpanda brokers and clients. +If you enable TLS encryption, you can also specify a certificate revocation list (`ca.crl`) so that Redpanda can check and reject connections from entities using certificates already revoked by a certificate authority (CA). All brokers can have the same `ca.crl`. The file must contain a single, concatenated list of certificate revocation lists (CRLs) for all issuing certificates in the truststore file. -To generate a self-signed certificate in a single command: +[[gen-certs]] +== Generate certificate files -[,bash] ----- -openssl req -new -newkey rsa:4096 -days 365 -nodes -x509 -keyout broker.key -out broker.crt -subj "/CN=redpanda" -addext "subjectAltName = DNS:localhost, IP: 127.0.0.1" ----- +This section shows you how to generate self-signed certificate files for your Redpanda brokers. If you already have your own, you can skip this step. -==== 1. Create CA configuration file (ca.cnf) +NOTE: Self-signed certificates are useful if you want to generate multiple certificates all signed by the same root. For example, you want to use mTLS but issue different certificates to multiple Redpanda brokers and clients. -Edit the `distinguished_name` section with your own organization details. For `default_md`, `sha256` is the minimum message digest level. The `subjectAltName` must be accurate for the broker's certificate. +=== Create a local CA for self-signed certificates -.ca.cnf -[,ini] +. Create a self-signed certificate and private key for the CA: ++ +[source,bash] +---- +openssl req -new -newkey rsa:4096 -days 365 -nodes -x509 -keyout broker.key -out broker.crt -subj "/CN=redpanda" -addext "subjectAltName = DNS:localhost, IP:127.0.0.1" +---- ++ +Ensure that `subjectAltName` is accurate for your setup. ++ +This command generates: ++ +- `broker.key`: Private key +- `broker.crt`: Self-signed certificate + +. Create a configuration file for the CA, `ca.cnf`, and include your organization's details. Ensure the `subjectAltName` extension is set correctly for broker certificates. ++ +[source,ini] ---- [ ca ] default_ca = CA_default @@ -55,47 +73,42 @@ default_md = sha256 copy_extensions = copy unique_subject = no policy = signing_policy -[ signing_policy ] -organizationName = supplied -commonName = optional -# Used to create the CA certificate. [ req ] prompt = no distinguished_name = distinguished_name x509_extensions = extensions [ distinguished_name ] -organizationName = Redpanda -commonName = Redpanda CA +organizationName = +commonName = [ extensions ] keyUsage = critical,digitalSignature,nonRepudiation,keyEncipherment,keyCertSign basicConstraints = critical,CA:true,pathlen:1 -# Common policy for nodes and users. [ signing_policy ] organizationName = supplied commonName = optional ---- -Create a CA key to self-sign certificates: - -[,bash] +. Create a private key for the CA and set its permissions: ++ +[source,bash] ---- openssl genrsa -out ca.key 2048 chmod 400 ca.key ---- -Create a public certificate for the CA: - -[,bash] +. Use the CA configuration to generate a public certificate: ++ +[source,bash] ---- openssl req -new -x509 -config ca.cnf -key ca.key -days 365 -batch -out ca.crt ---- - ++ where: - ++ [cols=",",options="header",] |=== |Inputs |Description @@ -113,23 +126,21 @@ certificates (created above). |`-batch` |Batch mode, where certificates are certified automatically. |=== ++ +The output `ca.crt` is the CA's public certificate, which you'll use in the truststore. -[cols=",",options="header",] -|=== -|Output |Description -|`-out ca.crt` |The public key certificate of the CA. -|=== - -=== Create certificate signing requests +=== Create broker certificates and certificate signing requests (CSRs) -This step creates the certificate signing request for the CA to extend trust over the broker's certificates. - -==== 1. Create broker configuration file (broker.cnf) +To issue certificates for brokers, create a certificate signing request (CSR) and sign it with the CA. +. Define the broker's Subject Alternative Name (SAN) entries in `broker.cnf` under `alt_names`. ++ A subject alternative name (SAN) indicates all domain names and IP addresses secured by the certificate. Depending on the address the client uses to connect to Redpanda, you might need to create a CNF file for each broker to modify the `alt_names` section with organizational details. For production usage, edit `alt_names` with DNS resolutions and/or the IP addresses. - -.broker.cnf -[,ini] ++ +For example: ++ +.`broker.cnf` +[source,ini] ---- [ req ] prompt = no @@ -137,7 +148,7 @@ distinguished_name = distinguished_name req_extensions = extensions [ distinguished_name ] -organizationName = Redpanda +organizationName = [ extensions ] subjectAltName = @alt_names @@ -150,23 +161,20 @@ DNS.4 = connect DNS.5 = ec2-3-15-15-272.us-east-2.compute.amazonaws.com IP.1 = 10.0.8.1 ---- - -You could configure alternative names with a single version of `broker.key`/`broker.crt`, -as long as you update the certificate for all brokers in the cluster any time you -edit an entry. For example: - -[,ini] ++ +You could configure alternative names with a single version of `broker.key`/`broker.crt`, as long as you update the certificate for all brokers in the cluster any time you edit an entry. For example: ++ +[source,ini] ---- [ alt_names ] DNS.1 = broker1.example.com DNS.2 = broker2.example.com DNS.3 = broker3.example.com ---- - -Additionally, you can configure alternative names using the public or private -IP addresses of all your brokers. For example: - -[,ini] ++ +Additionally, you can configure alternative names using the public or private IP addresses of all your brokers. For example: ++ +[source,ini] ---- [ alt_names ] IP.1 = 10.0.8.1 @@ -174,36 +182,22 @@ IP.2 = 10.0.8.2 IP.3 = 10.0.8.3 ---- -==== 2. Generate broker private key (broker.key) - -Generate a 2048-bit RSA private key for brokers: - -[,bash] +. Create a 2048-bit private key for the broker: ++ +[source,bash] ---- openssl genrsa -out broker.key 2048 ---- -where: - -[cols=",",options="header",] -|=== -|Output |Description -|`-out broker.key` |The private key certificate for the broker. -|=== - - -==== 3. Generate certificate signing request - -Before signing certificates, you must run the following command to generate the -broker's certificate signing request: - -[,bash] +. Create the broker's certificate signing request (CSR): ++ +[source,bash] ---- openssl req -new -key broker.key -out broker.csr -nodes -config broker.cnf ---- - ++ where: - ++ [cols=",",options="header",] |=== |Inputs |Description @@ -221,38 +215,52 @@ applying extensions. |`-in broker.csr` |Broker certificate signing request (CSR generated above). |=== ++ +The output `broker.crt` is the signed public key certificate for the broker. -[cols=",",options="header",] -|=== -|Output |Description -|`-out broker.crt` |The signed public key certificate for the broker. -|=== - -==== 4. Sign certificates - -Sign the certificate with the CA signature: - -[,bash] +. Sign the CSR with the CA's private key: ++ +[source,bash] ---- touch index.txt echo '01' > serial.txt openssl ca -config ca.cnf -keyfile ca.key -cert ca.crt -extensions extensions -in broker.csr -out broker.crt -outdir . -batch - -chown redpanda:redpanda broker.key broker.crt ca.crt -chmod 400 broker.key broker.crt ca.crt ---- - ++ If generated by a corporate CA, these certificate signing requests must be signed with the following extensions: - -[,bash] ++ +[,ini] ---- keyUsage = critical,digitalSignature,keyEncipherment extendedKeyUsage = serverAuth,clientAuth ---- +. Set ownership and permissions: ++ +[source,bash] +---- +chown redpanda:redpanda broker.key broker.crt ca.crt +chmod 400 broker.key broker.crt ca.crt +---- + == Configure TLS -To configure TLS, in `redpanda.yaml`, enter: +To configure TLS, in `redpanda.yaml`, enter either the standard <> or the <>. + +Choose PEM files when: + +- You are using FIPS mode compliance. +- You prefer file-based configurations with a separate key, certificate, and truststore file. + +Choose PKCS#12 bundles when: + +- FIPS mode is not required in your environment. +- You want a single, password-protected file that contains all certificates and keys. + +[[pem]] +=== Configure TLS with PEM files + +If you have separate files for `key_file`, `cert_file`, and `truststore_file`, use the following configuration in `redpanda.yaml`: .`redpanda.yaml` [,yaml] @@ -298,7 +306,7 @@ systemctl restart redpanda ==== [NOTE] -==== +==== If you replace a working `ca.crl` file with a file that contains an invalid certificate revocation list, such as an unsigned list, Redpanda will reject all connections until you either: * Replace the file. @@ -326,13 +334,44 @@ Schema Registry and HTTP Proxy connect to Redpanda over the Kafka API. If you co * xref:./authentication.adoc#configure-schema-registry-and-http-proxy-to-connect-to-redpanda-with-sasl[Configure Schema Registry and HTTP Proxy to connect to Redpanda with SASL] * xref:./listener-configuration.adoc[Configure Listeners] -include::manage:partial$min-tls-version.adoc[leveloffset=+1] +[[pkcs]] +=== Configure TLS with PKCS#12 bundles + +You can simplify certificate management by generating a password-protected PKCS#12 bundle from your `broker.key` and `broker.crt` files. + +NOTE: PKCS#12 keys are not supported when xref:manage:security/fips-compliance.adoc[FIPS mode] is enabled in Redpanda. The PKCS12KDF algorithm used in PKCS#12 is not FIPS-compliant. To use Redpanda in FIPS mode, configure your certificates and keys in <> instead. + +. Run this command to create a PKCS#12 file from your `broker.key` and `broker.crt` files: ++ +[source,bash] +---- +openssl pkcs12 -export -inkey broker.key -certfile broker.crt -passout pass: -out broker.p12 +---- ++ +Replace `` with your own password. + +. Update `redpanda.yaml` with the path to the PKCS#12 bundle: ++ +[source,yaml] +---- +redpanda: + kafka_api_tls: + - name: tls_listener + p12_path: + p12_password: + enabled: true + require_client_auth: false +---- + +CAUTION: Do not configure both both `key_file`/`cert_file` and `p12_path`/`p12_password` together, as this will cause a startup error. == Configure mTLS -To enable mTLS, add `require_client_auth` set to `true`. +To enable mTLS, add `require_client_auth` set to `true`. Configure either the standard PEM files or the PKCS#12 bundle. + +=== Configure mTLS with PEM files -For example, for the Kafka API, in `redpanda.yaml`, enter: +For the Kafka API, in `redpanda.yaml`, enter: .`redpanda.yaml` [,yaml] @@ -375,9 +414,9 @@ redpanda: - name: internal enabled: true require_client_auth: true - cert_file: - key_file: - truststore_file: + cert_file: + key_file: + truststore_file: ---- [NOTE] @@ -390,6 +429,25 @@ redpanda: See also: xref:./listener-configuration.adoc[Configure Listeners] +=== Configure mTLS with PKCS#12 bundles + +. Update `redpanda.yaml` with the path to the PKCS#12 bundle: ++ +[source,yaml] +---- +redpanda: + kafka_api_tls: + - name: mtls_listener + p12_path: + p12_password: + enabled: true + require_client_auth: true +---- + +CAUTION: Do not configure both the `key_file`/`cert_file` and the `p12_path`/`p12_password` together, as this will cause a startup error. + +include::manage:partial$min-tls-version.adoc[] + == Use rpk with TLS If you're using `rpk` to interact with the Kafka API using mTLS identity (for example, to manage topics or messages), pass the `--tls-key`, `--tls-cert`, and `--tls-truststore` flags to authenticate. diff --git a/modules/manage/pages/security/fips-compliance.adoc b/modules/manage/pages/security/fips-compliance.adoc index bdfbf2734e..d6152bb44b 100644 --- a/modules/manage/pages/security/fips-compliance.adoc +++ b/modules/manage/pages/security/fips-compliance.adoc @@ -9,11 +9,6 @@ Redpanda provides FIPS-compliant cipher enforcement for brokers using OpenSSL 3. include::shared:partial$enterprise-license.adoc[] ==== -[IMPORTANT] -==== -Redpanda is not fully FIPS-compliant when used with the Redpanda Helm chart and Operator in a Kubernetes deployment. -==== - To check if you already have a license key applied to your cluster: [,bash] @@ -25,7 +20,12 @@ rpk cluster license info Before configuring brokers to run in FIPS compliance mode (FIPS mode), check to make sure the `redpanda-rpk-fips` and `redpanda-fips` packages are xref:deploy:deployment-option/self-hosted/manual/production/production-deployment.adoc#install-redpanda-for-fips-compliance[installed]. These packages are required by both the `redpanda` and `redpanda-tuners` install packages. -== Configure FIPS +== Limitations + +- Redpanda is not fully FIPS-compliant when used with the Redpanda Helm chart and Operator in a Kubernetes deployment. +- PKCS#12 keys for xref:manage:security/encryption.adoc[TLS encryption] are not supported when FIPS mode is enabled in Redpanda. The PKCS12KDF algorithm used in PKCS#12 is not FIPS-compliant. To use Redpanda in FIPS mode with TLS enabled, configure your certificates and keys in PEM format instead. + +== Configure FIPS mode When you configure a broker to run in FIPS mode: