1
0
mirror of https://github.com/minio/docs.git synced 2025-05-28 00:41:14 +03:00
docs/source/includes/common/common-minio-kes-hashicorp.rst
Ravind Kumar 20403a7464
DOCS-912: Part 1: Cleaning up Vault (#949)
Staged:
http://192.241.195.202:9000/staging/DOCS-912/linux/operations/server-side-encryption/configure-minio-kes-hashicorp.html

---------

Co-authored-by: Andrea Longo <feorlen@users.noreply.github.com>
Co-authored-by: Daryl White <53910321+djwfyi@users.noreply.github.com>
2023-08-11 17:08:36 -04:00

3.9 KiB

uses a YAML-formatted configuration file. The following YAML provides the minimum required fields for using Hashicorp Vault as the root . You must modify this YAML to reflect your deployment environment.

address: 0.0.0.0:7373

# Disable the root administrator identity, as we do not need that level of access for
# supporting SSE operations.
admin: 
  identity: 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:  |kesconfigcertpath|kes-server.key
  cert: |kesconfigcertpath|kes-server.cert

  # Specify the path to CAs used by KES for validating client certificates
  # This can alternatively be a single CA
  # KES uses these CAs in addition to the system trust store for validating client certificates.

  ca: |kesconfigcertpath|CAs/

# Sets access policies for KES
# The `minio` policy grants access to the listed APIs.
policy:
  minio:
    allow:
    - /v1/key/create/*   # You can replace these wildcard '*' with a string prefix to restrict key names
    - /v1/key/generate/* # e.g. '/minio-'
    - /v1/key/decrypt/*
    - /v1/key/bulk/decrypt
    - /v1/key/list/*
    - /v1/status
    - /v1/metrics
    - /v1/log/audit
    - /v1/log/error
    identities:
    - MINIO_API_KEY_HASH # Replace with the hash output returned from kes identity new 

# Specify the connection information for the Vault server.
# The endpoint should be resolvable from the host.
# This example assumes that Vault is configured with an AppRole ID and
# Secret for use with KES.
keystore:
  vault:
    endpoint: https://HOSTNAME:8200
    engine: "/path/to/engine" # Replace with the path to the K/V Engine
    version: "v1|v2" # Specify v1 or v2 depending on the version of the K/V Engine
    approle:
      id: "VAULTAPPID"     # Hashicorp Vault AppRole ID
      secret: "VAULTAPPSECRET" # Hashicorp Vault AppRole Secret ID
      retry: 15s
    status:
      ping: 10s
    # Required if Vault uses certificates signed by an unknown CA,
    # e.g. self-signed or internal (non-globally trusted).  
    # Replace this value with the full path to the Vault CA certificate.
    tls:
      ca: vault-tls-CA.cert 

This procedure assumes an existing Hashicorp Vault installation accessible from the local host. The Vault Quick Start provides a sufficient foundation for the purposes of this procedure. Defer to the Vault Documentation for guidance on deployment and configuration.

KES Operations Require Unsealed Vault

You must unseal the Vault instance to allow any cryptographic operations, including key creation and retrieval. KES returns an error if the configured Vault service is sealed.

If you restart or otherwise seal the Vault instance, KES cannot perform any cryptographic operations against the Vault. You must unseal the Vault to ensure normal operations.

See the Vault documentation on Seal/Unseal for more information.

KES Operations Requires Unsealed Vault

You must unseal the Vault instance to allow normal cryptographic operations, including key creation or retrieval. See the Vault documentation on Seal/Unseal for more information.