mirror of
https://github.com/minio/docs.git
synced 2025-07-30 07:03:26 +03:00
Cleaning up Network Encryption pages
This commit is contained in:
Ravind Kumar
committed by
Ravind Kumar
Ravind Kumar
parent
8d15d1714a
commit
1c416561ef
@ -381,6 +381,8 @@ This includes configuring an external IDP such as :ref:`OpenID <minio-external-i
|
||||
|
||||
.. _create-tenant-security-section:
|
||||
|
||||
.. _minio-k8s-deploy-minio-tenant-security:
|
||||
|
||||
7) The :guilabel:`Security` Section
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
|
||||
@ -10,8 +10,44 @@ Modify a MinIO Tenant
|
||||
:local:
|
||||
:depth: 1
|
||||
|
||||
The procedures on this page use the :ref:`MinIO Operator Console <minio-operator-console>` 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) <https://en.wikipedia.org/wiki/Server_Name_Indication>`__, 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:
|
||||
|
||||
@ -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 <https://tools.ietf.org/html/rfc7568>`__ 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)
|
||||
<https://en.wikipedia.org/wiki/Server_Name_Indication>`__ 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 <https://tools.ietf.org/html/rfc7568>`__ 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 <minio-k8s-deploy-operator-tls>`,
|
||||
the MinIO Kubernetes Operator can automatically generate TLS certificates while :ref:`deploying <minio-k8s-deploy-minio-tenant-security>` or :ref:`modifying <minio-k8s-modify-minio-tenant-security>` 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 <concepts/services-networking/dns-pod-service/>` (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 <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 <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 <https://docs.microsoft.com/en-us/windows/deployment/usmt/usmt-recognized-environment-variables>`__ of the user running the MinIO Server process.
|
||||
|
||||
You can use the MinIO :minio-git:`certgen <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 <minio-k8s-deploy-minio-tenant-security>` or :ref:`modifying <minio-k8s-modify-minio-tenant-security>` the MinIO Tenant.
|
||||
|
||||
These custom certificates support `Server Name Indication (SNI) <https://en.wikipedia.org/wiki/Server_Name_Indication>`__, 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) <https://en.wikipedia.org/wiki/Server_Name_Indication>`__ 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) <https://en.wikipedia.org/wiki/Server_Name_Indication>`__ 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) <https://en.wikipedia.org/wiki/Server_Name_Indication>`__ 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 <https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf>`__) 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 <https://cs.opensource.google/go/go/+/refs/tags/go1.17.1:src/crypto/tls/cipher_suites.go;l=52>`__. 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 <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 <https://cs.opensource.google/go/go/+/refs/tags/go1.17.1:src/crypto/tls/cipher_suites.go;l=52>`__
|
||||
|
||||
.. 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
|
||||
<https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf>`__) 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 <minio-k8s-deploy-minio-tenant-security>` or :ref:`modifying <minio-k8s-modify-minio-tenant-security>` 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
|
||||
${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 <https://docs.microsoft.com/en-us/windows/deployment/usmt/usmt-recognized-environment-variables>`__ 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.
|
||||
|
||||
Reference in New Issue
Block a user