MinIO - 18. KMS 빠른 시작 가이드

목록

KMS Quickstart Guide

KMS 빠른 시작 가이드

MinIO uses a key-management-system (KMS) to support SSE-S3.

MinIO는 KMS (키 관리 시스템)를 사용하여 SSE-S3을 지원합니다.

If a client requests SSE-S3, or auto-encryption is enabled, the MinIO server encrypts each object with an unique object key which is protected by a master key managed by the KMS.

클라이언트가 SSE-S3을 요청하거나 자동 암호화가 활성화된 경우 MinIO 서버는 KMS에서 관리하는 마스터 키로 보호되는 고유한 객체 키로 각 객체를 암호화합니다.

Usually all object keys are protected by a single master key.

일반적으로 모든 객체 키는 단일 마스터 키로 보호됩니다.

MinIO supports two different KMS concepts:

MinIO는 두 가지 다른 KMS 개념을 지원합니다.

External KMS: MinIO can be configured to use an external KMS i.e. Hashicorp Vault. An external KMS decouples MinIO as storage system from key-management. An external KMS can be managed by a dedicated security team and allows you to grant/deny access to (certain) objects by enabling or disabling the corresponding master keys on demand.

외부 KMS: MinIO는 외부 KMS (예: Hashicorp Vault)를 사용하도록 구성할 수 있습니다. 외부 KMS는 MinIO를 키 관리에서 스토리지 시스템으로 분리합니다. 외부 KMS는 전담 보안 팀에서 관리할 수 있으며 요청 시 해당 마스터 키를 활성화하거나 비활성화하여 (특정) 객체에 대한 액세스를 허용/거부할 수 있습니다.

Direct KMS master keys: MinIO can also be configured to directly use a master key specified by the environment variable INIO_SSE_MASTER_KEY or with a docker secret key.

직접 KMS 마스터 키: 환경 변수 MINIO_SSE_MASTER_KEY 또는 docker 비밀 키로 지정된 마스터 키를 직접 사용하도록 MinIO를 구성할 수도 있습니다.

Direct master keys are useful if the storage backend is not on the same machine as the MinIO server, e.g., if network drives or MinIO gateway is used and an external KMS would cause too much management overhead.

직접 마스터 키는 스토리지 백엔드가 MinIO 서버와 동일한 시스템에 없는 경우 유용합니다. 예를 들어 네트워크 드라이브 또는 MinIO 게이트웨이가 사용되고 외부 KMS가 너무 많은 관리 오버헤드를 발생시키는 경우입니다.

Note: KMS master keys are mainly for testing purposes. It's not recommended to use them for production deployments. Further if the MinIO server machine is ever compromised, then the master key must also be treated as compromised.

메모: KMS 마스터 키는 주로 테스트 목적으로 사용됩니다. 프로덕션 배포에는 사용하지 않는 것이 좋습니다. 또한 MinIO 서버 시스템이 손상된 경우 마스터 키도 손상된 것으로 처리해야 합니다.

Important:

중요한 항목:

If multiple MinIO servers are configured as gateways pointing to the same backend - for example the same NAS storage - then the KMS configuration must be the same for all gateways.

여러 MinIO 서버가 동일한 백엔드 (예: 동일한 NAS 스토리지)를 가리키는 게이트웨이로 구성된 경우 KMS 구성은 모든 게이트웨이에 대해 동일해야 합니다.

Otherwise one gateway may not be able to decrypt objects created by another gateway. It is the operators' responsibility to ensure consistency.

그렇지 않으면 한 게이트웨이가 다른 게이트웨이에서 생성된 객체를 해독하지 못할 수도 있습니다. 일관성을 보장하는 것은 운영자의 책임입니다.

Get started

시작합니다

1. Prerequisites

1. 전제조건

Install MinIO - MinIO Quickstart Guide.

MinIO 설치 - MinIO 빠른 시작 가이드.

2. Setup a KMS

2. KMS 설정

Either use Hashicorp Vault as external KMS or specify a master key directly depending on your use case.

Hashicorp Vault를 외부 KMS로 사용하거나 사용 사례에 따라 마스터 키를 직접 지정하세요.

2.1 Setup Hashicorp Vault

2.1 Hashicorp Vault 설치

Here is a sample quick start for configuring vault with a transit backend and Approle with correct policy.

다음은 올바른 정책으로 전송 백엔드 및 Approle을 사용하여 자격 증명 모음을 구성하기 위한 샘플 빠른 시작입니다.

MinIO requires the following Vault setup:

MinIO에는 다음 Vault 설정이 필요합니다.

The transit backend configured with a named encryption key-ring

명명된 암호화 키링으로 구성된 전송 백엔드

AppRole based authentication with read/update policy for transit backend.

전송 백엔드에 대한 읽기/업데이트 정책을 사용한 AppRole 기반 인증입니다.

In particular, read and update policy are required for the Generate Data Key endpoint and Decrypt Data endpoint.

특히 데이터 키 생성 엔드포인트와 데이터 암호 해독 엔드포인트에는 읽기 및 업데이트 정책이 필요합니다.

2.1.1 Start Vault server

2.1.1 Vault 서버 시작

Vault requires access to mlock syscall by default. Use setcap to give the Vault executable the ability to use the mlock syscall without running the process as root. To do so run:

Vault에는 기본적으로 mlock syscall에 대한 액세스가 필요합니다. setcap을 사용하여 프로세스를 루트로 실행하지 않고도 Vault 실행 파일에 mlock syscall을 사용할 수 있는 기능을 제공합니다. 그렇게 하려면 다음을 실행하세요:

sudo setcap cap_ipc_lock=+ep $(readlink -f $(which vault))

Create vault-config.json to use file backend and start the server.

파일 백엔드를 사용하고 서버를 시작하려면 vault-config.json을 생성하세요.

cat > vault-config.json <

NOTE: In this example we use "tls_disable": true for demonstration purposes only, in production setup you should generate proper TLS certificates by specifying

메모: 이 예제에서는 데모 목적으로만 "tls_disable": true를 사용합니다. 프로덕션 설정에서는 다음을 지정하여 적절한 TLS 인증서를 생성해야 합니다:

tls_cert_file tls_key_file

2.1.2 Initialize vault and unseal it

2.1.2 볼트 초기화 및 봉인 해제

export VAULT_ADDR='http://127.0.0.1:8200' vault operator init Unseal Key 1: eyW/+8ZtsgT81Cb0e8OVxzJAQP5lY7Dcamnze+JnWEDT Unseal Key 2: 0tZn+7QQCxphpHwTm6/dC3LpP5JGIbYl6PK8Sy79R+P2 Unseal Key 3: cmhs+AUMXUuB6Lzsvgcbp3bRT6VDGQjgCBwB2xm0ANeF Unseal Key 4: /fTPpec5fWpGqWHK+uhnnTNMQyAbl5alUi4iq2yNgyqj Unseal Key 5: UPdDVPto+H6ko+20NKmagK40MOskqOBw4y/S51WpgVy/ Initial Root Token: s.zaU4Gbcu0Wh46uj2V3VuUde0

Vault is initialized with 5 key shares and a key threshold of 3.

Vault는 5 개의 키 공유와 3 개의 키 임계 값으로 초기화됩니다.

Please securely distribute the key shares printed above. When the Vault is re-sealed, restarted, or stopped, you must supply at least 3 of these keys to unseal it before it can start servicing requests.

위에 인쇄된 주요 주식을 안전하게 배포하시기 바랍니다. Vault가 다시 봉인되거나 다시 시작되거나 중지되면 요청 서비스를 시작하기 전에 봉인을 해제하기 위해 이러한 키 중 3개 이상을 제공해야 합니다.

Vault does not store the generated master key. Without at least 3 key to reconstruct the master key, Vault will remain permanently sealed!

Vault는 생성된 마스터 키를 저장하지 않습니다. 마스터 키를 재구성하기 위한 최소 3개의 키가 없으면 Vault는 영구적으로 봉인된 상태로 유지됩니다!

It is possible to generate new unseal keys, provided you have a quorum of existing unseal keys shares. See "vault operator rekey" for more information.

기존 잠금해제 키 공유의 쿼럼이 있는 경우 새 잠금해제 키를 생성할 수 있습니다. 자세한 내용은 "볼트 운영자 키 재설정"을 참조하세요.

Use any of the previously generated keys to unseal the vault

이전에 생성된 키를 사용하여 금고의 봉인을 해제하세요

vault operator unseal eyW/+8ZtsgT81Cb0e8OVxzJAQP5lY7Dcamnze+JnWEDT vault operator unseal 0tZn+7QQCxphpHwTm6/dC3LpP5JGIbYl6PK8Sy79R+P2 vault operator unseal cmhs+AUMXUuB6Lzsvgcbp3bRT6VDGQjgCBwB2xm0ANeF Key Value --- ----- Seal Type shamir Initialized true Sealed false ---> NOTE: vault is unsealed Total Shares 5 Threshold 3 Version 1.1.3 Cluster Name vault-cluster-3f084948 Cluster ID 8c92e999-7062-4da6-4434-0fc05f34824d HA Enabled false

Obtain root token from the vault operator init output above. It is displayed as Initial

위의 볼트 운영자 init 출력에서 루트 토큰을 얻습니다. 초기로 표시됩니다

Root Token: s.zaU4Gbcu0Wh46uj2V3VuUde0

2.1.3 Set up vault transit backend and create an app role

Vault 전송 백엔드 설정 및 앱 역할 생성

export VAULT_TOKEN=s.zaU4Gbcu0Wh46uj2V3VuUde0

vault auth enable approle

Vault 인증 활성화 approle

# enable approle style auth vault secrets enable transit

# approle 스타일 인증 저장소 비밀을 활성화하고 전송을 활성화합니다

# enable transit secrets engine # define an encryption key-ring for the transit path

# 전송 비밀 엔진을 활성화하고 전송 경로에 대한 암호화 키링을 정의합니다

vault write -f transit/keys/my-minio-key cat > vaultpolicy.hcl <

# define a policy for AppRole to access transit path

# AppRole이 전송 경로에 액세스하기 위한 정책을 정의합니다

vault policy write minio-policy ./vaultpolicy.hcl

# period indicates it is renewable if token is renewed before the period is over

# period는 기간이 끝나기 전에 토큰이 갱신되면 갱신 가능함을 나타냅니다

vault write auth/approle/role/my-role token_num_uses=0 secret_id_num_uses=0 period=5m

# define an AppRole

# AppRole을 정의합니다

vault write auth/approle/role/my-role policies=minio-policy

# apply policy to role

# 역할에 정책을 적용

vault read auth/approle/role/my-role/role-id

# get Approle ID

# 앱 ID를 얻습니다

Key Value --- ----- role_id 8c03926c-6c51-7a1d-cf7d-62e48ab8d6d7 vault write -f auth/approle/role/my-role/secret-id Key Value --- ----- secret_id edd8738c-6efe-c226-74f9-ef5b66e119d7 secret_id_accessor 57d1db64-6350-c321-4a3e-fc6aeb7d00b6

The AppRole ID, AppRole Secret Id, Vault endpoint and Vault key name can now be used to start minio server with Vault as KMS.

이제 AppRole ID, AppRole Secret ID, Vault 엔드포인트 및 Vault 키 이름을 사용하여 Vault를 KMS로 사용하여 미니오 서버를 시작할 수 있습니다.

2.1.3 Vault Environment variables

2.1.3 Vault 환경 변수

You'll need the Vault endpoint, AppRole ID, AppRole SecretID and encryption key-ring name defined in step 2.1.2

2.1.2 단계에서 정의한 Vault 엔드포인트, AppRole ID, AppRole SecretID 및 암호화 키 링 이름이 필요합니다.

export MINIO_SSE_VAULT_APPROLE_ID=8c03926c-6c51-7a1d-cf7d-62e48ab8d6d7 export MINIO_SSE_VAULT_APPROLE_SECRET=edd8738c-6efe-c226-74f9-ef5b66e119d7 export MINIO_SSE_VAULT_ENDPOINT=http://vault-endpoint-ip:8200 export MINIO_SSE_VAULT_KEY_NAME=my-minio-key export MINIO_SSE_VAULT_AUTH_TYPE=approle minio server ~/export

Optionally, set MINIO_SSE_VAULT_CAPATH to a directory of PEM-encoded CA cert files to use mTLS for client-server authentication.

선택적으로 클라이언트-서버 인증에 mTLS를 사용하려면 MINIO_SSE_VAULT_CAPATH를 PEM으로 인코딩된 CA 인증서 파일의 디렉터리로 설정하세요.

export MINIO_SSE_VAULT_CAPATH=/home/user/custom-certs

An additional option is to set MINIO_SSE_VAULT_NAMESPACE if AppRole and Transit Secrets engine have been scoped to Vault Namespace.

추가 옵션은 AppRole 및 Transit Secrets 엔진의 범위가 Vault 네임스페이스로 지정된 경우 MINIO_SSE_VAULT_NAMESPACE를 설정하는 것입니다.

export MINIO_SSE_VAULT_NAMESPACE=ns1

Note: If Vault Namespaces are in use, MINIO_SSE_VAULT_NAMESPACE variable needs to be set before setting approle and transit secrets engine.

메모: Vault 네임스페이스를 사용 중인 경우, 앱 및 전송 비밀 엔진을 설정하기 전에 MINIO_SSE_VAULT_NAMESPACE 변수를 설정해야 합니다.

MinIO gateway to S3 supports encryption. Three encryption modes are possible - encryption can be set to pass-through to backend, single encryption (at the gateway) or double encryption (single encryption at gateway and pass through to backend).

S3에 대한 MinIO 게이트웨이는 암호화를 지원합니다. 세 가지 암호화 모드가 가능합니다. 암호화는 백엔드 통과, 단일 암호화 (게이트웨이에서) 또는 이중 암호화 (게이트웨이에서 단일 암호화 및 백엔드 전달)로 설정할 수 있습니다.

This can be specified by setting MINIO_GATEWAY_SSE and KMS environment variables set in Step 2.1.2.

이는 2.1.2 단계에서 설정한 MINIO_GATEWAY_SSE 및 KMS 환경 변수를 설정하여 지정할 수 있습니다.

If MINIO_GATEWAY_SSE and KMS are not setup, all encryption headers are passed through to the backend. If KMS environment variables are set up, single encryption is automatically performed at the gateway and encrypted object is saved at the backend.

MINIO_GATEWAY_SSE 및 KMS가 설정되지 않은 경우, 모든 암호화 헤더가 백엔드로 전달됩니다. KMS 환경 변수를 설정하면 게이트웨이에서 자동으로 단일 암호화가 수행되고 암호화된 객체는 백엔드에 저장됩니다.

To specify double encryption, MINIO_GATEWAY_SSE environment variable needs to be set to "s3" for sse-s3 and "c" for sse-c encryption. More than one encryption option can be set, delimited by ";".

이중 암호화를 지정하려면, MINIO_GATEWAY_SSE 환경 변수를 sse-s3 암호화의 경우 "s3", sse-c 암호화의 경우 "c"로 설정해야 합니다. 둘 이상의 암호화 옵션을 ";"으로 구분하여 설정할 수 있습니다.

Objects are encrypted at the gateway and the gateway also does a pass-through to backend. Note that in the case of SSE-C encryption, gateway derives a unique SSE-C key for pass through from the SSE-C client key using a KDF.

객체는 게이트웨이에서 암호화되며 게이트웨이는 백엔드에 대한 통과도 수행합니다. SSE-C 암호화의 경우 게이트웨이는 KDF를 사용하여 SSE-C 클라이언트 키에서 통과를 위한 고유한 SSE-C 키를 파생합니다.

export MINIO_GATEWAY_SSE="s3;c" export MINIO_SSE_VAULT_APPROLE_ID=9b56cc08-8258-45d5-24a3-679876769126 export MINIO_SSE_VAULT_APPROLE_SECRET=4e30c52f-13e4-a6f5-0763-d50e8cb4321f export MINIO_SSE_VAULT_ENDPOINT=https://vault-endpoint-ip:8200 export MINIO_SSE_VAULT_KEY_NAME=my-minio-key export MINIO_SSE_VAULT_AUTH_TYPE=approle minio gateway s3

2.2 Specify a master key

2.2 마스터 키 지정

2.2.1 KMS master key from environment variables

2.2.1 환경 변수의 KMS 마스터 키

A KMS master key consists of a master-key ID (CMK) and the 256 bit master key encoded as HEX value separated by a :.

KMS 마스터 키는 마스터 키 ID (CMK)와 :으로 구분된 HEX(16진수 값) 값으로 인코딩된 256비트 마스터 키로 구성됩니다.

A KMS master key can be specified directly using:

KMS 마스터 키는 다음을 사용하여 직접 지정할 수 있습니다:

export MINIO_SSE_MASTER_KEY=my-minio-key:6368616e676520746869732070617373776f726420746f206120736563726574

Please use your own master key. A random master key can be generated using e.g. this command on Linux/Mac/BSD* systems:

자신의 마스터 키를 사용해 주세요. 예를 들어 Linux/Mac/BSD* 시스템에서 이 명령을 사용하여 임의의 마스터 키를 생성할 수 있습니다:

head -c 32 /dev/urandom | xxd -c 32 -ps

2.2.2 KMS master key from docker secret

2.2.2 docker 비밀의 KMS 마스터 키

Alternatively, you may pass a master key as a Docker secret.

또는 마스터 키를 Docker 비밀로 전달할 수도 있습니다.

echo "my-minio-key:6368616e676520746869732070617373776f726420746f206120736563726574" | docker secret create sse_master_key

Obviously, do not use this demo key for anything real!

분명히, 이 데모 키를 실제 용도로 사용하지 마십시오!

To use another secret name, follow the instructions above and replace sse_master_key with your custom names (e.g. my_sse_master_key).

다른 비밀 이름을 사용하려면 위의 지침을 따르고 sse_master_key를 사용자 정의 이름 (예; my_sse_master_key)으로 바꾸세요.

Then, set the MINIO_SSE_MASTER_KEY_FILE environment variable to your secret name:

그런 다음 MINIO_SSE_MASTER_KEY_FILE 환경 변수를 비밀 이름으로 설정합니다:

export MINIO_SSE_MASTER_KEY_FILE=my_sse_master_key

3. Test your setup

3. 설정 테스트

To test this setup, start minio server with environment variables set in Step 3, and server is ready to handle SSE-S3 requests.

이 설정을 테스트하려면, 3 단계에서 설정한 환경 변수를 사용하여 minio 서버를 시작하세요. 그러면 서버가 SSE-S3 요청을 처리할 준비가 됩니다.

Auto-Encryption

자동 암호화

MinIO can also enable auto-encryption if a valid KMS configuration is specified and the storage backend supports encrypted objects.

유효한 KMS 구성이 지정되고 스토리지 백엔드가 암호화된 객체를 지원하는 경우 MinIO는 자동 암호화를 활성화할 수도 있습니다.

Auto-Encryption, if enabled, ensures that all uploaded objects are encrypted using the specified KMS configuration.

자동 암호화를 활성화하면 업로드된 모든 객체가 지정된 KMS 구성을 사용하여 암호화됩니다.

Auto-Encryption is useful especially if the MinIO operator wants to ensure that objects are never stored in plaintext - for example if sensitive data is stored on public cloud storage. To enable auto-encryption set the environment variable to on:

자동 암호화는 특히 MinIO 운영자가 객체가 일반 텍스트로 저장되지 않도록 하려는 경우에 유용합니다. 예를 들어 민감한 데이터가 공용 클라우드 저장소에 저장되어 있는 경우입니다. 자동 암호화를 활성화하려면 환경 변수를 on으로 설정하십시오.

export MINIO_SSE_AUTO_ENCRYPTION=on

To verify auto-encryption, use the mc command:

자동 암호화를 확인하려면 mc 명령을 사용하십시오.

mc cp test.file myminio/crypt/ test.file: 5 B / 5 B ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ 100.00% 337 B/s 0s mc stat myminio/crypt/test.file Name : test.file ...

Encrypted :

암호화됨:

X-Amz-Server-Side-Encryption: AES256

X-Amz-Server-Side-Encryption: AES256

Note: Auto-Encryption only affects non-SSE-C requests since objects uploaded using SSE-C are already encrypted and S3 only allows either SSE-S3 or SSE-C but not both for the same object.

메모: SSE-C를 사용하여 업로드된 객체는 이미 암호화되어 있고 S3는 동일한 객체에 대해 SSE-S3 또는 SSE-C 중 하나만 허용하고 둘 다 허용하지 않기 때문에 자동 암호화는 SSE-C가 아닌 요청에만 영향을 미칩니다.

Explore Further

더 자세히 살펴보세요

Use mc with MinIO Server

MinIO 서버와 함께 mc 사용

Use aws-cli with MinIO Server

MinIO 서버와 함께 aws-cli 사용

Use s3cmd with MinIO Server

MinIO 서버와 함께 s3cmd 사용

Use minio-go SDK with MinIO Server

MinIO 서버와 함께 minio-go SDK 사용

The MinIO documentation website

MinIO 문서 웹 사이트