docs/source/security/server-side-encryption/configure-minio-kes-gcp.rst

Server-Side Object Encryption with GCP Secret Manager Root KMS

minio

Table of Contents

MinIO Server-Side Encryption (SSE) protects objects as part of write operations, allowing clients to take advantage of server processing power to secure objects at the storage layer (encryption-at-rest). SSE also provides key functionality to regulatory and compliance requirements around secure locking and erasure.

MinIO SSE uses Key Encryption Service (KES) <kes> and an external root Key Management Service (KMS) for performing secured cryptographic operations at scale. The root KMS provides stateful and secured storage of External Keys (EK) while KES (Key Encryption Service) is stateless and derives additional cryptographic keys from the root-managed EK (External Key).

This procedure does the following:

• Configure KES (Key Encryption Service) to use Google Cloud Platform Secret Manager as the root KMS (Key Management System).
• Configure MinIO to use the KES (Key Encryption Service) instance for supporting SSE (Server-Side Encryption).
• Configure automatic bucket-default SSE-KMS <minio-encryption-sse-kms> and SSE-S3 <minio-encryption-sse-s3>.

Prerequisites

GCP Secret Manager

This procedure assumes familiarity with GCP Secret Manager. The Secret Manager Quickstart provides a sufficient foundation for the purposes of this procedure.

MinIO specifically requires the following GCP settings or configurations:

• Enable Secret Manager in the project.

• Create a new GCP Service Account for supporting KES (Key Encryption Service). Ensure the user has a role with at minimum the following permissions:

  secretmanager.secrets.create
  secretmanager.secrets.delete
  secretmanager.secrets.get

  The Secret manager Admin role meets the minimum required permissions.

  GCP should return a set of credentials associated to the new service account, including private keys. Copy these credentials to a safe and secure location for use with this procedure.

Network Encryption (TLS)

Podman Container Manager

Enable MinIO Server-Side Encryption with GCP Secret Manager Root KMS

The following steps deploy Key Encryption Service (KES) <kes> configured to use an existing AWS KMS and Secrets Manager deployment as the root KMS for supporting SSE (Server-Side Encryption). These steps assume the AWS components meet the prerequisites <minio-sse-gcp-prereq-gcp>.

Prior to starting these steps, create the following folders:

mkdir -P ~/kes/certs ~/kes/config

1) Download the MinIO Key Encryption Service

2) Generate the TLS Private and Public Key for KES

3) Generate the TLS Private and Public Key for MinIO

4) Create the KES Configuration File

KES (Key Encryption Service) uses a YAML-formatted configuration file. The following example YAML specifies the minimum required fields for enabling SSE (Server-Side Encryption) using AWS Secrets Manager:

address: 0.0.0.0:7373

# Disable the root identity, as we do not need that level of access for
# supporting SSE operations.
root: disabled

# Specify the TLS keys generated in the previous step here
# For production environments, use keys signed by a known and trusted
# Certificate Authority (CA).
tls:
  key:  /data/certs/server.key
  cert: /data/certs/server.cert

# Create a policy named 'minio' that grants access to the 
# /create, /generate, and /decrypt KES APIs for any key name
# KES uses mTLS to grant access to this policy, where only the client 
# whose TLS certificate hash matches one of the "identities" can
# use this policy. Specify the hash of the MinIO server TLS certificate
# hash here.
policy:
  minio:
    allow:
    - /v1/key/create/*
    - /v1/key/generate/*
    - /v1/key/decrypt/*
    identities:
    - ${MINIO_IDENTITY_HASH} # Replace with the output of 'kes tool identity of minio-kes.cert'

# Specify the connection information for the  Secrets Manager endpoint.
# The endpoint should be resolvable from the host.
# This example assumes that the associated GCP account has the necessary
# access key and secret key
keystore:
  gcp:
    secretmanager:
      project_id: "${GCPPROJECTID}" # The GCP Project to use
      credentials:
        client_email: "${GCPCLIENTEMAIL}" # The client email for your GCP Credentials
        client_id: "${GCPCLIENTID}" # The Client ID for your GCP Credentials
        private_key_id: "${GCPPRIVATEKEYID}" # the private key ID for your GCP credentials
        private_key: "${GCPPRIVATEKEY}" # The content of your GCP Private Key

Save the configuration file as ~/kes/config/kes-config.yaml. Any field with value ${VARIABLE} uses the environment variable with matching name as the value. You can use this functionality to set credentials without writing them to the configuration file.

• Set MINIO_IDENTITY_HASH to the output of kes tool identity of minio-kes.cert.
• Set GCPPROJECTID to the GCP project for the Secrets Manager instance KES should use.
• Set GCPCLIENTEMAIL, GCPCLIENTID, GCPPRIVATEKEYID, and GCPPRIVATEKEY to the credentials associated to the GCP Service Account <minio-sse-gcp-prereq-gcp> KES should use when accessing the Secrets Manager service.

5) Start KES

6) Generate a Cryptographic Key

7) Configure MinIO to connect to KES

8) Enable Automatic Server-Side Encryption

SSE-KMS

The following command enables SSE-KMS on all objects written to the specified bucket:

mc mb ALIAS/encryptedbucket
mc encrypt set SSE-KMS encrypted-bucket-key ALIAS/encryptedbucket

Replace ALIAS with the alias <mc alias> of the MinIO deployment configured in the previous step.

Write a file to the bucket using mc cp or any S3-compatible SDK with a PutObject function. You can then run mc stat on the file to confirm the associated encryption metadata.

SSE-S3

The following command enables SSE-S3 on all objects written to the specified bucket. MinIO uses the MINIO_KMS_KES_KEY_NAME key for performing SSE (Server-Side Encryption).

mc mb ALIAS/encryptedbucket
mc encrypt set SSE-S3 ALIAS/encryptedbucket

Replace ALIAS with the alias <mc alias> of the MinIO deployment configured in the previous step.

Write a file to the bucket using mc cp or any S3-compatible SDK with a PutObject function. You can then run mc stat on the file to confirm the associated encryption metadata.

Configuration Reference for GCP Secret Manager Root KMS

The following section describes each of the Key Encryption Service (KES) <kes> configuration settings for using GCP Secrets Manager as the root Key Management Service (KMS) for SSE (Server-Side Encryption):

YAML Overview

The following YAML describes the minimum required fields for configuring GCP Secret Manager as an external KMS for supporting SSE (Server-Side Encryption).

Any field with value ${VARIABLE} uses the environment variable with matching name as the value. You can use this functionality to set credentials without writing them to the configuration file.

address: 0.0.0.0:7373
root: ${ROOT_IDENTITY}

tls:
  key: kes-server.key
  cert: kes-server.cert

policy:
  minio-server:
    allow:
      - /v1/key/create/*
      - /v1/key/generate/*
      - /v1/key/decrypt/*
    identities:
    - ${MINIO_IDENTITY}

keys:
  - name: "minio-encryption-key-alpha"
  - name: "minio-encryption-key-baker"
  - name: "minio-encryption-key-charlie"

keystore:
  gcp:
    secretmanager:
      project_id: "${GCPPROJECTID}"
      credentials:
        client_email: "${GCPCLIENTEMAIL}"
        client_id: "${GCPCLIENTID}"
        private_key_id: "${GCPPRIVATEKEYID}"
        private_key: "${GCPPRIVATEKEY}"

Reference

Key	Description
address
root
tls
policy
keys
keystore.gcp.secretmanager	The configuration for the GCP Secret Manager project_id - The GCP Project of the Secret Manager instance. credentials - Replace the credentials with the credentials for a project user with the required permissions <minio-sse-gcp-prereq-gcp>.