Overview Return the name, ID, and creation information about a cryptographic key. Output resembles the following: Name my-key ID 14eb17aec10cd31a6bc006ba81d63589 Created At 2023-03-09 18:16:11 Created By 3ecfcdf38fcbe141ae26a1030f81e96b753365a46760ae6b578698a97c59fd22 Syntax kes key info \ <name> \ [--color <string>] \ [--insecure, -k] \ [--json] Parameters name Required

Overview Decrypt the contents of a data encryption key and return the plaintext value. Use the plaintext value for encrypting or decrypting data using the DEK. Avoid storing the plaintext value of a DEK on disk, as it allows decryption of data without requiring access to the secret key used to generate the DEK. Syntax kes key decrypt \ <name> \ <ciphertext> \ [<context>] \ [--insecure,-k] Parameters name Required

Overview Add a new cryptographic key and store it in the configured Key Management System. KES never returns the generated secret to clients. Syntax kes key create \ <name> \ [--insecure, -k] Parameters name Required

Overview The kes migrate command supports migrating master keys from one KMS instance to another KMS instance. For example, you can use the command to migrate a Hashicorp Vault instance to another Hashicorp Vault instance. Or, kes migrate can migrate a Hashicorp Vault instance to or from an AWS Secrets Manager KMS.

AIStor Key Manager is a robust key management server designed to securely store cryptographic keys and other sensitive data. Key Manager provides similar functionality to third-party Key Management Services (KMS), such as an HTTP API for en/decrypting operations, scalable design, high availability, high performance, and low latency. Architecture A Key Manager cluster consists of at least one server or host. Each node in the cluster consists of a full replica that can service read and write operations.

The Key Manager supports a YAML-formatted configuration file for specifying startup options and settings. The file has the following format: # Config file version # REQUIRED # version: v1 # System admin configuration # Optional # #admin: # Identity with sysadmin privileges. # Generate a new identity using `minkms identity` # Use the corresponding secret `k1:KEY` when authenticating as a client to # perform operations with this identity # If you omit this value, MinKMS generates and emits the root credentials # to the systemlog on startup. # identity: h1:Rvxa7nj8zkL48CeDkN6LhpX-K7KK6uhIhpBOcTHNhWw # Interval in which the cluster leader sends heartbeats to all its followers # OPTIONAL # # If 0, a reasonable default is selected automatically. It should be # at least twice the network latency between any two KMS cluster nodes. # Reasonable values are between 50ms and 1s for most clusters. # # Very low (below 50ms) or high (above 1.5s) values should only be set # under special circumstances. For example, a stretch cluster spawned # across geographic regions may demand larger heartbeat intervals due to # higher network latency. # # A too low value may cause sporadic leadership losses similar to a flaky # or unreliable network. A too high value may cause delayed detection of # node failures and longer write-quorum recovery after node failures. # However, it does not affect the strict consistency guarantees or # correctness of state changes. # # The default setting is typically sufficient # # heartbeat: 500ms # TLS configuration # Required # # Key Manager requires TLS for encrypting and protecting all connections. # tls: certs: # You must specify *at least* one TLS keypair. # # You can specify multiple key-cert pairs to MinKMS to cover multiple # hostnames if necessary. # # MinKMS must have read access to the specified paths to start. # - key: /etc/minkms/private.key # Path to the server's TLS private key cert: /etc/minkms/public.crt # Path to the server's TLS certificate # A folder containing one or more CA root certificates # MinKMS uses this for validating TLS certificates for a remote system # This is optional and typically not required during normal installations # ca: /etc/minkms/CAs

This page documents migration of encryption keys from the legacy MinIO Key Encryption Service (KES) to AIStor Key Manager. Key Manager holds all cryptographic keys in an encrypted format without relying on an external keystore. Once you complete this operation, you can switch your AIStor deployments to use Key Manager for supporting Server Side Encryption operations. Migration of cryptographic keys is a critical operation that can lead to data loss if performed incorrectly. Before proceeding, you must do the following:

Overview Manage KES secrets. Subcommands Subcommands Description create Create a new secret info Get information about a secret ls List secrets rm Remove a secret show Display a secret

Overview The kes server command starts a MinIO Key Encryption Server (KES) server. The kes server handles requests for creating and retrieving cryptography keys from a supported Key Management System (KMS). KES is a required component for enabling Server-Side Object Encryption in AIStor Object Stores using a 3rd party KMS solution.

Monitoring Guidelines Volume Manager nodes export Prometheus compatible metrics data via port 10443. To scrape data in Prometheus, each node must be accessible by port 10443. Make node server metrics port accessible by localhost:8080. kubectl -n directpv port-forward node-server-4nd6q 8080:10443 Add the following to your Prometheus configuration: