Enterprise Object Storage Encryption

As data travels between the object storage and the application, it might bounce between any number of unknown and/or untrusted networks. Encrypting data as it travels over the network (also called 'over-the-wire') successfully mitigates man-in-the-middle attacks and ensures that data remains secure regardless of the route it takes.

MinIO supports Transport Layer Security (TLS) v1.2+ between all components in the cluster. This approach ensures there are no weak links in either inter or intra-cluster encrypted traffic. TLS is a ubiquitous encryption framework: it’s what puts the s in https and is the same encryption protocol used by banks, e-commerce sites and other enterprise-grade systems that rely on data storage encryption.

MinIO's TLS implementation is optimized at the CPU instruction level and has negligible performance overhead. It only requires the specification of a TLS private key and public certificate for each MinIO server in the cluster. For Kubernetes environments, the MinIO Kubernetes Operator has integrated/automatic TLS certificate generation and allocation as part of the tenant deployment process. MinIO supports multiple TLS certificates, where each certificate corresponds to a specific domain name. MinIO uses Server Name Indication (SNI) to determine which certificate to serve for any given request.

Data stored on disk relies entirely on the security of the disk and by extension the host system to keep that data safe. MinIO Server-Side Object Encryption automatically encrypts data before it's stored on disk (encryption at rest). This approach guarantees that no data is written to disk unencrypted. This baseline layer of security assures the confidentiality, integrity and authenticity of the data at rest. MinIO supports both client-driven and automatic bucket-default object encryption for maximum flexibility around data encryption.

MinIO Server-Side encryption is compatible with Amazon AWS-S3 semantics (SSE-S3). MinIO extends the baseline support for the AWS KMS to include common AIStor KMS systems such as Hashicorp Vault and Thales Ciphertrust (formerly Gemalto KeySecure). MinIO also supports client-driven encryption (SSE-C), where the application can specify a data key for use with encrypting an object. For both SSE-S3 and SSE-C, the MinIO server performs all encryption operations, including key rotation and re-encryption of objects.

With automatic server-side encryption, MinIO encrypts each object with a unique key and applies multiple layers of additional encryption using both on-the-fly encryption keys and keys derived from the external KMS or client-provided key. This secure and sophisticated approach takes place within MinIO without the need to juggle multiple independent kernel and user-space cryptography utilities.

MinIO uses an authentication encryption scheme (AEAD) to en/decrypt objects as they are written to or read from object storage. MinIO AEAD encryption supports industry standard encryption protocols such as AES-256-GCM and ChaCha20-Poly1305 to secure object data. MinIO's CPU-level optimizations such as SIMD acceleration ensure negligible performance overhead of en/decryption operations. Organizations can run automatic bucket-level encryption at all times rather than being forced into sub-optimal security choices.

MinIO offers a built-in option for key encryption. MinIO’s Key Encryption Service (KES) is a stateless and distributed key-management system for high-performance applications. It is designed to be run inside Kubernetes and distribute cryptographic keys to applications. KES is a required component for MinIO Server-Side Object Encryption (SSE-S3).KES supports encryption operations on a MinIO cluster and is a key mechanism for ensuring scalable and performant encryption operations. KES works as an intermediary between the MinIO cluster and the external KMS, generating encryption keys and performing encryption operations as needed and unconstrained by the limitations of the KMS. As a result, there is still one central KMS protecting master keys and acting as the root of trust within the infrastructure. KES simplifies deployment and management by removing the need to spin up a KMS per set of applications. Instead, an application can request a data encryption key (DEK) from a KES server or ask the KES server to decrypt an encrypted DEK.

Since the KES server is completely stateless it can be scaled automatically, for example via the Kubernetes horizontal autoscaler. At the same time the load on the central KMS does not increase significantly as KES serves the vast majority of application requests independently.

For Kubernetes environments, the MinIO Kubernetes Operator supports deploying and configuring KES for each tenant, enabling SSE-S3 as part of each tenant deployment.