Deploy the Key Manager onto the new node Follow the installation instructions Add the Key Manager node to the existing cluster Use the minkms add command to add the node to the existing cluster. You must run this command from a node already part of the cluster: minkms add -a ROOT_API_KEY keymanager-01.example.net:7373 The ROOT_API_KEY is distinct from the REK. Retrieve the Root API Key from its secure location, such as a dedicated secrets vault. If you have root access to an existing Key Manager host, you can access the host and review the minkms journal to get the server startup logs and identify the key, prefixed with k1.

This section documents steps for installing and managing AIStor Key Manager on Kubernetes infrastructure using a distribution that follows the upstream API and functionality. This procedure assumes that the user interacting with the Kubernetes cluster has authorization to: Install Kubernetes operators and associated resources including CustomResourceDefinitions, Statefulsets, and secrets into new or existing namespaces and Perform operations as a user that has broad permissions to create resources within multiple namespaces. Deploy AIStor Key Manager using Helm This procedure documents installation on Kubernetes with the AIStor Helm Charts.

The following sections describe the version 2 endpoints and metrics. Cluster metrics You can scrape cluster-level metrics using the following URL endpoint: http://HOSTNAME:PORT/minio/v2/metrics/cluster Replace HOSTNAME:PORT with the FQDN and port of the AIStor deployment. For deployments with a load balancer managing connections between AIStor nodes, specify the address of the load balancer.

Overview Create a new KES identity. You cannot add identities to a stateless KES implementation with this command. Instead, define the identities for stateless implementations in the config file. The output of the command resembles the following:

The output is similar to what is available via journalctl -uf minio for systemd-controlled deployments. Use the mc admin logs command to show Object Store logs. To enable or disable the sending of logs to SUBNET for support, use mc support callhome. The uploading feature remains disabled by default until explicitly enabled for a deployment on an opt-in only basis. Syntax Example The following command displays the most recent ten server logs of any type for the alias minio1.

The mc admin accesskey create command adds a new access key and secret key pair for an existing AIStor user. Syntax Example The following command creates a new access key associated to an existing AIStor user:

The mc admin user disable command disables an AIStor user on the target AIStor deployment. Clients cannot use the user credentials to authenticate to the AIStor deployment. Disabling a user does not remove that user from the deployment. Use mc admin user enable to enable a disabled user on an AIStor deployment. To manage external Identity Provider users, see OIDC or AD/LDAP. Syntax Example The following command disables user myuser on the myminio AIStor deployment:

Description The mc admin cluster iam command and its subcommands provide tools for manually importing and exporting AIStor identity and access management (IAM) metadata. For automatic synchronization of all IAM configurations in a deployment to a remote site, use site replication.

Permission This command requires that the user performing it have the admin:Rebalance policy action for the deployment. Description The mc admin rebalance command allows starts, monitors, or stops a rebalancing operation on an AIStor deployment. Rebalancing redistributes objects across all pools in the deployment.

The mc admin user ls command lists all AIStor users on the target AIStor deployment. The mc admin user list command has equivalent functionality to mc admin user ls. mc admin user ls does not return the access key or secret key associated to a user. Use mc admin user info to retrieve detailed user information, including the user access key. To manage external Identity Provider users, see OIDC or AD/LDAP.