diff --git a/Makefile b/Makefile index ee33b0c8..0139e428 100644 --- a/Makefile +++ b/Makefile @@ -124,14 +124,6 @@ sync-minio-version: ;; \ esac -# @if [ "$(shell git diff --name-only | grep 'conf.py')" == "" ]; then \ -# echo "MinIO Server Version already latest"; \ -# else \ -# echo "New MinIO Server Version available ${MINIO}" ; \ -# #git add source/conf.py && git commit -m "Updating MinIO server to ${MINIO}"; \ -# fi - - sync-cpp-docs: # C++ repo does not have any releases yet. @echo "Retrieving C++ docs from github.com/minio/minio-js" diff --git a/source/default-conf.py b/source/default-conf.py index a334091d..b5421b99 100644 --- a/source/default-conf.py +++ b/source/default-conf.py @@ -103,12 +103,13 @@ exclude_patterns = ['includes/*', '*-template.rst'] if tags.has("linux"): excludes = [ - 'operations/install-deploy-manage/minio-k8s-deploy-minio-tenant.rst', + 'operations/install-deploy-manage/deploy-minio-tenant.rst', 'operations/install-deploy-manage/modify-minio-tenant.rst', 'operations/install-deploy-manage/expand-minio-tenant.rst', 'operations/install-deploy-manage/upgrade-minio-tenant.rst', 'operations/install-deploy-manage/upgrade-minio-operator.rst', 'operations/install-deploy-manage/delete-minio-tenant.rst', + 'operations/install-deploy-manage/minio-operator-console.rst', 'operations/deploy-manage-tenants.rst', 'reference/kubectl-minio-plugin.rst', 'reference/kubectl-minio-plugin/kubectl-minio-delete.rst', @@ -126,12 +127,13 @@ if tags.has("linux"): ] elif tags.has("macos"): excludes = [ - 'operations/install-deploy-manage/minio-k8s-deploy-minio-tenant.rst', + 'operations/install-deploy-manage/deploy-minio-tenant.rst', 'operations/install-deploy-manage/modify-minio-tenant.rst', 'operations/install-deploy-manage/expand-minio-tenant.rst', 'operations/install-deploy-manage/upgrade-minio-tenant.rst', 'operations/install-deploy-manage/upgrade-minio-operator.rst', 'operations/install-deploy-manage/delete-minio-tenant.rst', + 'operations/install-deploy-manage/minio-operator-console.rst', 'operations/deploy-manage-tenants.rst', 'reference/kubectl-minio-plugin.rst', 'reference/kubectl-minio-plugin/kubectl-minio-delete.rst', @@ -149,12 +151,13 @@ elif tags.has("macos"): ] elif tags.has("windows"): excludes = [ - 'operations/install-deploy-manage/minio-k8s-deploy-minio-tenant.rst', + 'operations/install-deploy-manage/deploy-minio-tenant.rst', 'operations/install-deploy-manage/modify-minio-tenant.rst', 'operations/install-deploy-manage/expand-minio-tenant.rst', 'operations/install-deploy-manage/upgrade-minio-tenant.rst', 'operations/install-deploy-manage/upgrade-minio-operator.rst', 'operations/install-deploy-manage/delete-minio-tenant.rst', + 'operations/install-deploy-manage/minio-operator-console.rst', 'operations/deploy-manage-tenants.rst', 'reference/kubectl-minio-plugin.rst', 'reference/kubectl-minio-plugin/kubectl-minio-delete.rst', diff --git a/source/images/k8s/operator-manage-tenant.png b/source/images/k8s/operator-manage-tenant.png index b15ff0a2..b1b1d43a 100644 Binary files a/source/images/k8s/operator-manage-tenant.png and b/source/images/k8s/operator-manage-tenant.png differ diff --git a/source/includes/k8s/deploy-operator.rst b/source/includes/k8s/deploy-operator.rst index 16dbfd4a..9919f847 100644 --- a/source/includes/k8s/deploy-operator.rst +++ b/source/includes/k8s/deploy-operator.rst @@ -57,24 +57,22 @@ the MinIO Operator or Plugin v4.0.0 or later. This procedure assumes that your local host machine has both the correct version of ``kubectl`` for your Kubernetes cluster *and* the necessary access to that cluster to create new resources. +.. _minio-k8s-deploy-operator-tls: + Kubernetes TLS Certificate API ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The MinIO Operator automatically generates TLS Certificate Signing Requests -(CSR) and uses the Kubernetes ``certificates.k8s.io`` -:kube-docs:`TLS certificate management API -` to create signed TLS certificates. +The MinIO Operator automatically generates TLS Certificate Signing Requests (CSR) and uses the Kubernetes ``certificates.k8s.io`` :kube-docs:`TLS certificate management API ` to create signed TLS certificates. -The MinIO Operator therefore *requires* that the Kubernetes -``kube-controller-manager`` configuration include the following -:kube-docs:`configuration settings -`: +The MinIO Operator therefore *requires* that the Kubernetes ``kube-controller-manager`` configuration include the following :kube-docs:`configuration settings `: -- ``--cluster-signing-key-file`` - Specify the PEM-encoded RSA or ECDSA private - key used to sign cluster-scoped certificates. +- ``--cluster-signing-key-file`` - Specify the PEM-encoded RSA or ECDSA private key used to sign cluster-scoped certificates. -- ``--cluster-signing-cert-file`` - Specify the PEM-encoded x.509 Certificate - Authority certificate used to issue cluster-scoped certificates. +- ``--cluster-signing-cert-file`` - Specify the PEM-encoded x.509 Certificate Authority certificate used to issue cluster-scoped certificates. + +The Kubernetes TLS API uses the CA signature algorithm for generating new TLS certificate. +MinIO recommends ECDSA (e.g. `NIST P-256 curve `__) or EdDSA (e.g. :rfc:`Curve25519 <7748>`) TLS private keys/certificates due to their lower computation requirements compared to RSA. +See :ref:`minio-TLS-supported-cipher-suites` for a complete list of supported TLS Cipher Suites. The Operator cannot complete initialization if the Kubernetes cluster is not configured to respond to a generated CSR. Certain Kubernetes diff --git a/source/operations/install-deploy-manage/deploy-minio-tenant.rst b/source/operations/install-deploy-manage/deploy-minio-tenant.rst index 1af03e88..5c2d7a3b 100644 --- a/source/operations/install-deploy-manage/deploy-minio-tenant.rst +++ b/source/operations/install-deploy-manage/deploy-minio-tenant.rst @@ -381,6 +381,8 @@ This includes configuring an external IDP such as :ref:`OpenID ` for modifying an existing tenant. -Stub: TODO +.. image:: /images/k8s/operator-manage-tenant.png + :align: center + :width: 70% + :class: no-scaled-link + :alt: MinIO Operator Tenant Console + +.. _minio-k8s-modify-minio-tenant-security: + +Modify Tenant TLS Configuration +------------------------------- + +The MinIO Operator Console supports adding and removing TLS certificates from a MinIO Tenant. + +From the Operator Console view, select the Tenant to open the summary view, then select :guilabel:`Security`. +You can make the following modifications: + +Enable or Disable TLS + Toggle the :guilabel:`TLS` switch to direct the Operator to either enable or disable TLS for the deployment. + The MinIO Operator automatically generates the necessary TLS certificates using the Kubernetes TLS API. + See :ref:`minio-tls-user-generated` for more information. + +Add Custom TLS Certificates + MinIO Tenants support `Server Name Indication (SNI) `__, where the MinIO server identifies which certificate to use based on the hostname specified by the connecting client. + The MinIO Operator can attach additional TLS certificates to the Tenant to enable SNI-based TLS connectivity. + + To customize the TLS certificates mounted on the MinIO Tenant, enable the :guilabel:`Custom Certificates` switch. + Select the :guilabel:`Add Certificate +` button to add custom TLS certificates. + +Add Trusted Certificate Authorities + The MinIO Tenant validates the TLS certificate presented by each connecting client against the host system's trusted root certificate store. + The MinIO Operator can attach additional third-party Certificate Authorities (CA) to the Tenant to allow validation of client TLS certificates signed by those CAs. + + To customize the trusted CAs mounted to each Tenant MinIO pod, enable the :guilabel:`Custom Certificates` switch. + Select the :guilabel:`Add CA Certificate +` button to add third party CA certificates. + + If the MinIO Tenant cannot match an incoming client's TLS certificate issuer against either the container OS's trust store *or* an explicitly attached CA, MinIO rejects the connection as invalid. .. Following link is intended for K8s only .. _minio-decommissioning: diff --git a/source/operations/network-encryption.rst b/source/operations/network-encryption.rst index 56724881..9e8ea747 100644 --- a/source/operations/network-encryption.rst +++ b/source/operations/network-encryption.rst @@ -10,256 +10,343 @@ Network Encryption (TLS) :local: :depth: 1 -The MinIO server supports Transport Layer Security (TLS) encryption of incoming -and outgoing traffic. MinIO recommends all MinIO servers run with TLS enabled to -ensure end-to-end security of client-server or server-server transmissions. +MinIO supports Transport Layer Security (TLS) 1.2+ encryption of incoming and outgoing traffic. -TLS is the successor to Secure Socket Layer (SSL) encryption. SSL is fully -`deprecated `__ as of June 30th, 2018. -MinIO uses only supported (non-deprecated) TLS protocols (TLS 1.2 and later). +.. admonition:: SSL is Deprecated + :class: note -MinIO supports multiple TLS certificates, where the server uses -`Server Name Indication (SNI) -`__ to identify which -certificate to use when responding to a client request. + TLS is the successor to Secure Socket Layer (SSL) encryption. + SSL is fully `deprecated `__ as of June 30th, 2018. -For example, consider a MinIO deployment reachable through the following -hostnames: +.. _minio-tls-user-generated: -- ``https://minio.example.net`` -- ``https://s3.example.net`` -- ``https://minio.internal-example.net`` +Enabling TLS +------------ -MinIO can have a single TLS certificate that covers all hostnames with multiple -Subject Alternative Names (SAN). However, this would reveal the -``internal-example.net`` hostname to all clients. Instead, you can specify -multiple TLS certificates to MinIO for the public and private portions of your -infrastructure to mitigate the risk of leaking internal topologies via TLS SAN. -When a client connects using a specific hostname, MinIO uses SNI to select the -appropriate TLS certificate for that hostname. +.. cond:: k8s -MinIO by default searches an OS-specific directory for TLS keys and -certificates. For deployments started with a custom TLS directory -:mc-cmd:`minio server --certs-dir`, use that directory instead of the -defaults. + For Kubernetes clusters with a valid :ref:`TLS Cluster Signing Certificate `, + the MinIO Kubernetes Operator can automatically generate TLS certificates while :ref:`deploying ` or :ref:`modifying ` a MinIO Tenant. + The TLS certificate generation process is as follows: + + - The Operator generates a Certificate Signing Request (CSR) associated to the Tenant. + The :abbr:`CSR (Certificate Signing Request)` includes the appropriate DNS SubjectAlternateNames (SAN) for the Tenant services and pods. + + The Operator then waits for :abbr:`CSR (Certificate Signing Request)` approval + + - The :abbr:`CSR (Certificate Signing Request)` waits pending approval. + The Kubernetes TLS API can automatically approve the :abbr:`CSR (Certificate Signing Request)` if properly configured. + Otherwise, a cluster administrator must manually approve the :abbr:`CSR (Certificate Signing Request)` before Kubernetes can generate the necessary certificates. + + - The Operator applies the generated TLS Certificates to each MinIO Pod in the Tenant. + + The Kubernetes TLS API uses the Kubernetes cluster Certificate Authority (CA) signature algorithm when generating new TLS certificates. + See :ref:`minio-TLS-supported-cipher-suites` for a complete list of MinIO's supported TLS Cipher Suites and recommended signature algorithms. + + By default, Kubernetes places a certificate bundle on each pod at ``/var/run/secrets/kubernetes.io/serviceaccount/ca.crt``. + This CA bundle should include the cluster or root CA used to sign the MinIO Tenant TLS certificates. + Other applications deployed within the Kubernetes cluster can trust this cluster certificate to connect to a MinIO Tenant using the :kube-docs:`MinIO service DNS name ` (e.g. ``https://minio.minio-tenant-1.svc.cluster-domain.example:443``). + +.. cond:: linux + + The MinIO server searches the following directory for TLS keys and certificates: + + .. code-block:: shell + + ${HOME}/.minio/certs + + Where ``${HOME}`` is the home directory of the user running the MinIO Server process. + + For deployments started with a custom TLS directory :mc-cmd:`minio server --certs-dir`, use that directory instead of the defaults. + + Place the TLS certificates for the default domain (e.g. ``minio.example.net``) in the ``/certs`` directory, with the private key as ``private.key`` and public certificate as ``public.crt``. + + For example: + + .. code-block:: shell + + ${HOME}/.minio/certs + private.key + public.crt + + You can use the MinIO :minio-git:`certgen ` to mint self-signed certificates for enabling TLS for evaluating MinIO with TLS enabled. + For example, the following command generates a self-signed certificate with a set of IP and DNS SANs associated to the MinIO Server hosts: + + .. code-block:: shell + + certgen -host "localhost,minio-*.example.net" + + You can place the generated ``public.crt`` and ``private.key`` into the ``/.minio/certs`` directory to enable TLS for the MinIO deployment. + Applications can use the ``public.crt`` as a trusted Certificate Authority to allow connections to the MinIO deployment without disabling certificate validation. + +.. cond:: macos + + The MinIO server searches the following directory for TLS keys and certificates: + + .. code-block:: shell + + ${HOME}/.minio/certs + + For deployments started with a custom TLS directory :mc-cmd:`minio server --certs-dir`, use that directory instead of the defaults. + + Place the TLS certificates for the default domain (e.g. ``minio.example.net``) in the ``/certs`` directory, with the private key as ``private.key`` and public certificate as ``public.crt``. + + For example: + + .. code-block:: shell + + ${HOME}/.minio/certs + private.key + public.crt + + Where ``${HOME}`` is the home directory of the user running the MinIO Server process. + + You can use the MinIO :minio-git:`certgen ` to mint self-signed certificates for enabling TLS for evaluating MinIO with TLS enabled. + For example, the following command generates a self-signed certificate with a set of IP and DNS SANs associated to the MinIO Server hosts: + + .. code-block:: shell + + certgen -host "localhost,minio-*.example.net" + + You can place the generated ``public.crt`` and ``private.key`` into the ``/.minio/certs`` directory to enable TLS for the MinIO deployment. + Applications can use the ``public.crt`` as a trusted Certificate Authority to allow connections to the MinIO deployment without disabling certificate validation. + +.. cond:: windows + + The MinIO server searches the following directory for TLS keys and certificates: + + .. code-block:: shell + + %%USERPROFILE%%\.minio\certs + + For deployments started with a custom TLS directory :mc-cmd:`minio server --certs-dir`, use that directory instead of the defaults. + + Place the TLS certificates for the default domain (e.g. ``minio.example.net``) in the ``/certs`` directory, with the private key as ``private.key`` and public certificate as ``public.crt``. + + For example: + + .. code-block:: shell + + %%USERPROFILE%%\.minio\certs + private.key + public.crt + + Where ``%%USERPROFILE%%`` is the location of the `User Profile folder `__ of the user running the MinIO Server process. + + You can use the MinIO :minio-git:`certgen ` to mint self-signed certificates for enabling TLS for evaluating MinIO with TLS enabled. + For example, the following command generates a self-signed certificate with a set of IP and DNS SANs associated to the MinIO Server hosts: + + .. code-block:: shell + + certgen.exe -host "localhost,minio-*.example.net" + + You can place the generated ``public.crt`` and ``private.key`` into the ``\.minio\certs`` directory to enable TLS for the MinIO deployment. + Applications can use the ``public.crt`` as a trusted Certificate Authority to allow connections to the MinIO deployment without disabling certificate validation. + + +Multiple Domain-Based TLS Certificates +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. cond:: k8s + + The MinIO Operator supports attaching user-specified TLS certificates when :ref:`deploying ` or :ref:`modifying ` the MinIO Tenant. + + These custom certificates support `Server Name Indication (SNI) `__, where the MinIO server identifies which certificate to use based on the hostname specified by the connecting client. + For example, you can generate certificates signed by your organization's preferred Certificate Authority (CA) and attach those to the MinIO Tenant. + Applications which trust that :abbr:`CA (Certificate Authority)` can connect to the MinIO Tenant and fully validate the Tenant TLS certificates. + +.. cond:: linux + + The MinIO server supports multiple TLS certificates, where the server uses `Server Name Indication (SNI) `__ to identify which certificate to use when responding to a client request. + When a client connects using a specific hostname, MinIO uses :abbr:`SNI (Server Name Indication)` to select the appropriate TLS certificate for that hostname. + + For example, consider a MinIO deployment reachable through the following hostnames: + + - ``https://minio.example.net`` (default TLS certificates) + - ``https://s3.example.net`` + - ``https://minio.internal-example.net`` + + Create a subfolder in ``/certs`` for each additional domain for which MinIO should present TLS certificates. + While MinIO has no requirements for folder names, consider creating subfolders whose name matches the domain to improve human readability. + Place the TLS private and public key for that domain in the subfolder. + + For example: + + .. code-block:: shell + + ${HOME}/.minio/certs + private.key + public.crt + s3-example.net/ + private.key + public.crt + internal-example.net/ + private.key + public.crt + + While you can have a single TLS certificate that covers all hostnames with multiple Subject Alternative Names (SAN), this would reveal the ``internal-example.net`` and ``s3-example.net`` hostnames to any client which inspects the server certificate. + Using a TLS certificate per hostname better protects each individual hostname from discovery. + + If the client-specified hostname or IP address does not match any of the configured TLS certificates, the connection typically fails with a certificate validation error. + +.. cond:: macos + + The MinIO server supports multiple TLS certificates, where the server uses `Server Name Indication (SNI) `__ to identify which certificate to use when responding to a client request. + When a client connects using a specific hostname, MinIO uses SNI to select the appropriate TLS certificate for that hostname. + + For example, consider a MinIO deployment reachable through the following hostnames: + + - ``https://minio.example.net`` (default TLS certificates) + - ``https://s3.example.net`` + - ``https://minio.internal-example.net`` + + Create a subfolder in ``/certs`` for each additional domain for which MinIO should present TLS certificates. + While MinIO has no requirements for folder names, consider creating subfolders whose name matches the domain to improve human readability. + Place the TLS private and public key for that domain in the subfolder. + + For example: + + .. code-block:: shell + + ${HOME}/.minio/certs + private.key + public.crt + s3-example.net/ + private.key + public.crt + internal-example.net/ + private.key + public.crt + + While you can have a single TLS certificate that covers all hostnames with multiple Subject Alternative Names (SAN), this would reveal the ``internal-example.net`` and ``s3-example.net`` hostnames to any client which inspects the server certificate. + Using a TLS certificate per hostname better protects each individual hostname from discovery. + + If the client-specified hostname or IP address does not match any of the configured TLS certificates, the connection typically fails with a certificate validation error. + +.. cond:: windows + + The MinIO server supports multiple TLS certificates, where the server uses `Server Name Indication (SNI) `__ to identify which certificate to use when responding to a client request. + When a client connects using a specific hostname, MinIO uses SNI to select the appropriate TLS certificate for that hostname. + + For example, consider a MinIO deployment reachable through the following hostnames: + + - ``https://minio.example.net`` (default TLS certificates) + - ``https://s3.example.net`` + - ``https://minio.internal-example.net`` + + Create a subfolder in ``/certs`` for each additional domain for which MinIO should present TLS certificates. + While MinIO has no requirements for folder names, consider creating subfolders whose name matches the domain to improve human readability. + Place the TLS private and public key for that domain in the subfolder. + + For example: + + .. code-block:: shell + + %%USERPROFILE%%\.minio\certs + private.key + public.crt + s3-example.net\ + private.key + public.crt + internal-example.net\ + private.key + public.crt + + While you can have a single TLS certificate that covers all hostnames with multiple Subject Alternative Names (SAN), this would reveal the ``internal-example.net`` and ``s3-example.net`` hostnames to any client which inspects the server certificate. + Using a TLS certificate per hostname better protects each individual hostname from discovery. + + If the client-specified hostname or IP address does not match any of the configured TLS certificates, the connection typically fails with a certificate validation error. + +.. _minio-TLS-supported-cipher-suites: + +Supported TLS Cipher Suites +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +MinIO recommends generating ECDSA (e.g. `NIST P-256 curve `__) or EdDSA (e.g. :rfc:`Curve25519 <7748>`) TLS private keys/certificates due to their lower computation requirements compared to RSA. + +MinIO supports the following TLS 1.2 and 1.3 cipher suites as supported by `Go `__. The lists mark recommended algorithms with a :octicon:`star-fill` icon: .. tab-set:: - .. tab-item:: Linux - :sync: linux + .. tab-item:: TLS 1.3 - MinIO looks for TLS keys in the following directory: + - ``TLS_CHACHA20_POLY1305_SHA256`` :octicon:`star-fill` + - ``TLS_AES_128_GCM_SHA256`` + - ``TLS_AES_256_GCM_SHA384`` - .. code-block:: shell + .. tab-item:: TLS 1.2 - ${HOME}/.minio/certs - - Place the TLS certificates for the default domain (e.g. - ``minio.example.net``) in the ``/certs`` directory, with the private key - as ``private.key`` and public certificate as ``public.crt``. - - Create a subfolder in ``/certs`` for each additional domain for which - MinIO should present TLS certificates. While MinIO has no requirements for - folder names, consider creating subfolders whose name matches the domain - to improve human readability. Place the TLS private and public key for - that domain in the subfolder. - - For example: - - .. code-block:: shell - - ${HOME}/.minio/certs - private.key - public.crt - s3-example.net/ - private.key - public.crt - internal-example.net/ - private.key - public.crt - - .. tab-item:: OSX - :sync: osx - - MinIO looks for TLS keys in the following directory: - - .. code-block:: shell - - ${HOME}/.minio/certs - - Place the TLS certificates for the default domain (e.g. - ``minio.example.net``) in the ``/certs`` directory, with the private key - as ``private.key`` and public certificate as ``public.crt``. - - Create a subfolder in ``/certs`` for each additional domain for which - MinIO should present TLS certificates. While MinIO has no requirements for - folder names, consider creating subfolders whose name matches the domain - to improve human readability. Place the TLS private and public key for - that domain in the subfolder. - - For example: - - .. code-block:: shell - - ${HOME}/.minio/certs - private.key - public.crt - s3-example.net/ - private.key - public.crt - internal-example.net/ - private.key - public.crt - - .. tab-item:: Windows - :sync: windows - - MinIO looks for TLS keys in the following directory: - - .. code-block:: shell - - %%USERPROFILE%%\.minio\certs - - Place the TLS certificates for the default domain (e.g. - ``minio.example.net``) in the ``\certs`` directory, with the private key - as ``private.key`` and public certificate as ``public.crt``. - - Create a subfolder in ``\certs`` for each additional domain for which - MinIO should present TLS certificates. While MinIO has no requirements for - folder names, consider creating subfolders whose name matches the domain - to improve human readability. Place the TLS private and public key for - that domain in the subfolder. - - For example: - - .. code-block:: shell - - %%USERPROFILE%%\.minio\certs - private.key - public.crt - s3-example.net\ - private.key - public.crt - internal-example.net\ - private.key - public.crt - -.. admonition:: MinIO Console TLS Connectivity - :class: important - - The :ref:`MinIO Console ` automatically connects via - TLS if the MinIO server supports it. However, the Console *by default* - attempts to connect using the IP address of the MinIO Server. - - The MinIO Console may fail to connect and throw login errors if this IP - address is not included as a - :rfc:`Subject Alternative Name <5280#section-4.2.1.6>` in any configured - TLS certificate. - - Set the :envvar:`MINIO_SERVER_URL` environment variable to a resolvable - DNS hostname covered by one of the configured TLS SANs. This allows - the Console to properly validate the certificate and connect to MinIO. - -Supported TLS Cipher Suites ---------------------------- - -MinIO supports the following TLS 1.2 and 1.3 cipher suites as -supported by -`Go `__ - -.. list-table:: - :header-rows: 1 - :widths: 60 20 20 - :width: 100% - - * - Cipher - - TLS 1.2 - - TLS 1.3 - - * - ``TLS_CHACHA20_POLY1305_SHA256`` - - - - :octicon:`check` - - * - ``TLS_AES_128_GCM_SHA256`` - - - - :octicon:`check` - - * - ``TLS_AES_256_GCM_SHA384`` - - - - :octicon:`check` - - * - ``TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305`` - - :octicon:`check` - - - - * - ``TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305`` - - :octicon:`check` - - - - * - ``TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256`` - - :octicon:`check` - - - - * - ``TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256`` - - :octicon:`check` - - - - * - ``TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384`` - - :octicon:`check` - - - - * - ``TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384`` - - :octicon:`check` - - - -.. admonition:: Use ECDSA/EdDSA over RSA when when generating certificates - :class: note - - TLS certificates created using Elliptic Curve Cryptography (ECC) have lower - computation requirements compared to RSA. Specifically, MinIO recommends - generating ECDSA (e.g. `NIST P-256 curve - `__) or EdDSA - (e.g. :rfc:`Curve25519 <7748>`) TLS private keys/certificates wherever - possible. + - ``TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305`` :octicon:`star-fill` + - ``TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256`` :octicon:`star-fill` + - ``TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384`` :octicon:`star-fill` + - ``TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305`` + - ``TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256`` + - ``TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384`` Third-Party Certificate Authorities ----------------------------------- -MinIO by default uses the Operating System's trusted certificate store for -validating TLS certificates presented by a connecting client. +.. cond:: k8s -For clients connecting with certificates signed by an untrusted Certificate -Authority (CA) (e.g. self-signed, private/internal, etc.), you can provide the -necessary CA key for MinIO to explicitly trust: + The MinIO Kubernetes Operator can automatically attach third-party Certificate Authorities when :ref:`deploying ` or :ref:`modifying ` a MinIO Tenant. + + You can add, update, or remove CAs from the tenant at any time. + You must restart the MinIO Tenant for the changes to the configured CAs to apply. + + The Operator places the specified CAs on each MinIO Server pod such that all pods have a consistent set of trusted CAs. -MinIO by default searches an OS-specific directory for Certificate Authority -certificates. For deployments started with a custom TLS directory -:mc-cmd:`minio server --certs-dir`, use that directory instead of the -defaults. + If the MinIO Server cannot match an incoming client's TLS certificate issuer against any of the available CAs, the server rejects the connection as invalid. -.. tab-set:: +.. cond:: linux - .. tab-item:: Linux - :sync: linux + The MinIO Server validates the TLS certificate presented by each connecting client against the host system's trusted root certificate store. - MinIO looks for Certificate Authority keys in the following directory: + You can place additional trusted Certificate Authority files in the following directory: - .. code-block:: shell + .. code-block:: shell - ${HOME}/.minio/certs/CAs + ${HOME}/.minio/certs/CAs - .. tab-item:: OSX + Where ``${HOME}`` is the home directory of the user running the MinIO Server process. - MinIO looks for Certificate Authority keys in the following directory: + For deployments started with a custom TLS directory :mc-cmd:`minio server --certs-dir`, the server searches in the ``/CAs`` path at that specified directory. - .. code-block:: shell + Place the certificate file for each CA into the ``/CAs`` subdirectory. + Ensure all hosts in the MinIO deployment have a consistent set of trusted CAs in that directory. + If the MinIO Server cannot match an incoming client's TLS certificate issuer against any of the available CAs, the server rejects the connection as invalid. - ${HOME}/.minio/certs/CAs +.. cond:: macos - .. tab-item:: Windows + The MinIO Server validates the TLS certificate presented by each connecting client against the host system's trusted root certificate store. - MinIO looks for Certificate Authority keys in the following directory: + You can place additional trusted Certificate Authority files in the following directory: - .. code-block:: shell + .. code-block:: shell - %%USERPROFILE%%\.minio\certs\CAs \ No newline at end of file + ${HOME}/.minio/certs/CAs + + Where ``${HOME}`` is the home directory of the user running the MinIO Server process. + + For deployments started with a custom TLS directory :mc-cmd:`minio server --certs-dir`, the server searches in the ``/certs/CAs`` path at that specified directory. + + Place the certificate file for each CA into the ``/CAs`` subdirectory. + Ensure all hosts in the MinIO deployment have a consistent set of trusted CAs in that directory. + If the MinIO Server cannot match an incoming client's TLS certificate issuer against any of the available CAs, the server rejects the connection as invalid. + +.. cond:: windows + + The MinIO Server validates the TLS certificate presented by each connecting client against the host system's trusted root certificate store. + + You can place additional trusted Certificate Authority files in the following directory: + + .. code-block:: shell + + %%USERPROFILE%%\.minio\certs\CAs + + Where ``%%USERPROFILE%%`` is the location of the `User Profile folder `__ of the user running the MinIO Server process. + + For deployments started with a custom TLS directory :mc-cmd:`minio server --certs-dir`, the server searches in the ``\CAs`` path at that specified directory. + + Place the certificate file for each CA into the ``/CAs`` subdirectory. + Ensure all hosts in the MinIO deployment have a consistent set of trusted CAs in that directory. + If the MinIO Server cannot match an incoming client's TLS certificate issuer against any of the available CAs, the server rejects the connection as invalid.