Home GitHub
Buckit Object Storage User Guide

Network Encryption (TLS)

Note

If you deploy a new cluster using Guided Deployment using Buckit Manager, the deployment wizard configures TLS as part of the cluster setup.

SSL is Deprecated

TLS is the successor to Secure Socket Layer (SSL) encryption. SSL is fully deprecated as of June 30th, 2018.

Overview

Buckit supports Transport Layer Security (TLS) 1.2+ encryption of incoming and outgoing traffic. Buckit can automatically detect certificates specified to either a default or custom search path and enable TLS for all connections. Buckit supports Server Name Indication (SNI) requests from clients, where Buckit attempts to locate the appropriate TLS certificate for the hostname specified by the client.

Buckit requires at minimum a single default TLS certificate and can support multiple TLS certificates in support of SNI connectivity. Buckit uses the TLS Subject Alternate Name (SAN) list to determine which certificate to return to the client. If Buckit cannot find a TLS certificate whose SAN covers the client-requested hostname, Buckit uses the default certificate and attempts to establish the handshake.

You can specify a single TLS certificate which covers all possible SANs for which the Buckit deployment accepts connections.

This configuration requires the least configuration, but necessarily exposes all hostnames configured in the TLS SAN to connecting clients. Depending on your TLS configuration, this may include internal or private SAN domains.

You can instead specify multiple TLS certificates separated by domain(s) with a single default certificate for any non-matching hostname requests. This configuration requires more configuration, but only exposes those hostnames configured in the returned TLS SAN array.

TLS for Buckit

The Buckit Server searches for TLS keys and certificates for each node and uses those credentials for enabling TLS. Buckit automatically enables TLS upon discovery and validation of certificates. Specify a path for the Buckit server to search for certificates using buckit server --certs-dir or -S.

For example, the following command fragment directs the Buckit process to use the /opt/buckit/certs directory for TLS certificates.

buckit server --certs-dir /opt/buckit/certs ...

For systemd-managed deployments, modify MINIO_OPTS in /etc/default/minio to include the --certs-dir option.

The user running the Buckit service must have read and write permissions to this directory.

Place the TLS certificates for the default domain (e.g. buckit.example.net) in the /certs directory, with the private key as private.key and public certificate as public.crt.

For distributed Buckit deployments, each node in the deployment must have matching TLS certificate configurations.

Self-signed, Internal, Private Certificates, and Public CAs with Intermediate Certificates

If using Certificates signed by a non-global or non-public Certificate Authority, or if using a global CA that requires the use of intermediate certificates, you must provide those CAs to the Buckit Server. If the Buckit server does not have the necessary CAs, it may return warnings or errors related to TLS validation when connecting to other services.

Place the CA certificates in the /certs/CAs folder under the configured certificate directory.

The following example assumes the Buckit Server was started with --certs-dir /opt/buckit/certs:

mv myCA.crt /opt/buckit/certs/CAs/

For a self-signed certificate, the Certificate Authority is typically the private key used to sign the cert.

For certificates signed by an internal, private, or other non-global Certificate Authority, use the same CA that signed the cert. A non-global CA must include the full chain of trust from the intermediate certificate to the root.

If the provided file is not an X.509 certificate, Buckit ignores it and may return errors for validating certificates signed by that CA.

Third-Party Certificate Authorities

The Buckit Server validates the TLS certificate presented by each connecting client against the host system’s trusted root certificate store.

Place the CA certificates in the /certs/CAs folder under the configured certificate directory.

The following example assumes the Buckit Server was started with --certs-dir /opt/buckit/certs:

mv myCA.crt /opt/buckit/certs/CAs/

Place the certificate file for each CA into the /CAs subdirectory. Ensure all hosts in the Buckit deployment have a consistent set of trusted CAs in that directory. If the Buckit Server cannot match an incoming client’s TLS certificate issuer against any of the available CAs, the server rejects the connection as invalid.

Supported TLS Cipher Suites

Buckit recommends generating ECDSA (e.g. NIST P-256 curve) or EdDSA (e.g. Curve25519) TLS private keys/certificates due to their lower computation requirements compared to RSA.

Buckit supports the following TLS 1.2 and 1.3 cipher suites as supported by Go. The lists mark recommended algorithms with a icon:

  • TLS_CHACHA20_POLY1305_SHA256

  • TLS_AES_128_GCM_SHA256

  • TLS_AES_256_GCM_SHA384

  • TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305

  • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

  • TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305

  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

Buckit documentation adapted from MinIO Open Source documentation. Licensed under the Creative Commons Attribution 4.0 International License. Creative Commons License