Document support for PKCS#12

modules/get-started/pages/whats-new.adoc

@@ -47,6 +47,8 @@ This release includes several updates to xref:get-started:licensing/overview.ado
 
 - *Unified license management in Redpanda Console*: You can now upload and apply a single license key for both Redpanda Console and the connected Redpanda cluster through the Redpanda Console UI. Any existing license key is overridden by the new one.
 
+- *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.
+
 == PKCS#12 support for TLS listeners
 
 Redpanda now supports configuring TLS using PKCS#12 files, allowing you to manage both the certificate and private key in a single, password-protected file.
@@ -55,6 +57,44 @@ 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:
+
+- Create and manage Redpanda users and their authentication settings.
+- Define and manage ACLs to control access to Redpanda resources.
+- Automatically reconcile changes to users and ACLs using the Redpanda Operator.
+
+To learn more, see the xref:manage:kubernetes/security/authentication/k-user-controller.adoc[User custom resource documentation].
+
+=== 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:
+
+- Define, create, and manage Avro, Protobuf, and JSON schemas declaratively.
+- Enforce schema compatibility and evolution policies directly in Kubernetes.
+- Automate schema lifecycle management alongside Redpanda deployments.
+
+To learn more, see the xref:manage:kubernetes/k-schema-controller.adoc[Schema custom resource documentation].
+
+=== 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:
+
+- `useFlux: true` (default): Delegates Redpanda resource management to Flux controllers through HelmRelease resources.
+- `useFlux: false`: Directly manages resources within the Redpanda Operator, bypassing Flux.
+
+Example:
+
+[,yaml]
+----
+spec:
+  clusterSpec:
+    useFlux: false
+----
+
 == New commands
 
 The following `rpk` commands are new in this version:

modules/manage/pages/security/encryption.adoc

@@ -14,24 +14,33 @@ By default, Redpanda data is sent unencrypted. A security best practice is to en
 
 TLS certificates are required for encryption. You can use your own certificates, either self-signed or issued by a trusted CA.
 
-You'll need:
-
+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.
+--
 
-For mTLS, client certificates signed by the same CA are also required.
+Ensure these files are readable by Redpanda and protected against unauthorized access:
 
-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.
+[,bash]
+----
+chmod 400 broker.key broker.crt ca.crt
+chown redpanda:redpanda broker.key broker.crt ca.crt
+----
+
+For mTLS, client certificates signed by the same CA are also required.
 
 If you don't already have these files, you can learn how to generate them in <<Create a local CA for self-signed certificates>>.
 
+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.
+
 [[gen-certs]]
 == Generate certificate files
 
 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.
 
-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.
+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.
 
 === Create a local CA for self-signed certificates
 
@@ -236,8 +245,19 @@ chmod 400 broker.key broker.crt ca.crt
 
 == Configure TLS
 
-To configure TLS, in `redpanda.yaml`, enter either the standard PEM configuration files or the PKCS#12 bundle configuration.
+To configure TLS, in `redpanda.yaml`, enter either the standard <<pem,PEM configuration files>> or the <<pkcs,PKCS#12 bundle configuration>>.
+
+Choose PEM files when:
 
+- You are using FIPS mode compliance.
+- You prefer file-based configurations with 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 `key_file`, `cert_file`, and `truststore_file`, use the following configuration in `redpanda.yaml`:
@@ -314,11 +334,12 @@ 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]
 
+[[pkcs]]
 === Configure TLS with PKCS#12 bundles
 
-You can simplify certificate management by using a PKCS#12 bundle.
+You can simplify certificate management by generating a password-protected PKCS#12 bundle from your `broker.key` and `broker.crt` files.
 
-NOTE: If you haven't generated the `.key` and `.crt` files, refer to <<gen-certs, Generate certificate 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 <<pem,PEM format>> instead.
 
 . Run this command to create a PKCS#12 file from your `broker.key` and `broker.crt` files:
 +
@@ -410,8 +431,6 @@ See also: xref:./listener-configuration.adoc[Configure Listeners]
 
 === Configure mTLS with PKCS#12 bundles
 
-You can simplify certificate management by using a PKCS#12 bundle.
-
 . Update `redpanda.yaml` with the path to the PKCS#12 bundle:
 +
 [source,yaml]

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: