The AIStor Access Management Plugin provides a REST interface for offloading authorization through a webhook service. AIStor sends the request and credential details for every API call to the configured external HTTP(S) endpoint and looks for a response of ALLOW or DENY. AIStor can therefore delegate the access management to the external system instead of relying on S3 policy based access control. Configuration Settings You can configure the AIStor External Access Management Plugin using the following environment variables or configuration settings.

You can use the AIStor Console to perform several of the bucket and object management and interaction functions available in AIStor. Depending on the permissions and IAM policies for the authenticated user, you can: Browse, upload, revert, manage, and interact with objects. Browse, create, and manage buckets. Create or monitor remote tiers for object transition rules. Object Browser The Object Browser lists the buckets and objects the authenticated user has access to on the deployment.

AIStor Object Locking (“Object Retention”) enforces Write-Once Read-Many (WORM) immutability to protect versioned objects from deletion. AIStor supports both duration based object retention and indefinite legal hold retention. AIStor Object Locking provides key data retention compliance and meets SEC17a-4(f), FINRA 4511(C), and CFTC 1.31(c)-(d) requirements as per Cohasset Associates. Overview

AIStor supports expanding an existing distributed deployment by adding a new Server Pool. Each pool expands the total available storage capacity of the cluster. Expansion does not provide Business Continuity/Disaster Recovery (BC/DR)-grade protections. While each pool is an independent set of servers with distinct erasure sets for availability, the complete loss of one pool results in MinIO stopping I/O for all pools in the deployment. Similarly, an erasure set which loses quorum in one pool represents data loss of objects stored in that set, regardless of the number of other erasure sets or pools.

The mc admin accesskey info command returns a description of the specified access key(s). The description output includes the following details, as available: Access Key Parent user of the specified access key Access key status (on or off) Policy or policies Comment Expiration Syntax Example The following command returns information on the specified access key:

The mc admin accesskey ls command lists users, access keys, or temporary security token service keys managed by the AIStor deployment. You can use mc admin accesskey ls as an alias to this command. Syntax Example The following command lists all access keys associated to the user with username admin1 on the deployment at alias myminio:

The mc admin accesskey enable command enables an existing access key. The command requires the access key to exist and be currently disabled. Syntax Example The following command enables the access key myuseraccesskey on the myminio deployment:

The mc admin accesskey rm command removes an access key associated to a user on the deployment. The command requires the access key to exist. Syntax Example The following command removes the access key myuseraccesskey from the myminio deployment:

The mc admin heal command scans for objects that are damaged or corrupted and heals those objects. mc admin heal is resource intensive and typically not required as a manual process, even after drive failures or corruption events. As a part of normal operations, MinIO: automatically heals objects damaged by silent bit rot corruption, drive failure, or other issues on each POST or GET operation. performs periodic background object healing using the scanner. aggressively heals objects after drive replacement. Refer to Object Healing for more details on how AIStor heals objects.

The mc admin accesskey disable command disables an existing access key for a MinIO IDP user. Syntax Example The following command disables the specified access key: