AIStor uses Policy-Based Access Control (PBAC) to define the authorized actions and resources to which an authenticated user has access. Each policy describes one or more actions and conditions that outline the permissions of a user or group of users. AIStor PBAC is built for compatibility with AWS IAM policy syntax, structure, and behavior. This documentation makes a best-effort to cover IAM-specific behavior and functionality. Refer also to the AWS IAM documentation for more information.

Use the following checklist when planning the software configuration for a production, distributed MinIO deployment. AIStor pre-requisites Description ☐ Servers running a Linux operating system with a kernel of 6.6.x or later for access to critical performance features.Red Hat Enterprise Linux (RHEL) 10 and Ubuntu Server 24.04 LTS use appropriate kernel versions by default. ☐ A method to synchronize time servers across nodes, such as with ntp, timedatectl or timesyncd.The method to use varies by operating system.Check with your operating system’s documentation for how to synchronize time with a time server. ☐ Disable system services that index, scan, or audit the filesystem, system-level calls, or kernel-level calls.These services can reduce performance due to resource contention or interception of AIStor operations.MinIO strongly recommends uninstalling or disabling the following services on hosts running AIStor:- mlocate or plocate- updatedb- auditd- Crowdstrike Falcon- Antivirus software (clamav)The above list represents the most common services or softwares known to cause performance or behavioral issues with high performance systems like AIStor.Consider removing or disabling any other service or software which functions similarly to those listed above on AIStor hosts.Alternatively, configure these services to ignore or exclude the AIStor process and all drives or drive paths accessed by AIStor. ☐ System administrator access to the remote servers ☐ A management tool for distributed systems, such as Ansible, Terraform, or Kubernetes for orchestrated environments.Kubernetes infrastructures should use the MinIO Operator for best results. ☐ Load balancer to handle routing of requests (for example, NGINX) ☐ Prometheus or a Prometheus-compatible setup for monitoring and metrics ☐ Grafana or similar Prometheus-compatible visual dashboard ☐ (Optional) mc installed on the local host system AIStor install Install a matching version of AIStor across all nodes in the deployment.

This page documents the installation and management of AIStor object storage using MinIO’s Red Hat OpenShift-certified operator. This procedure assumes that the user interacting with the OpenShift cluster has authorization to: Install Kubernetes operators and associated resources including CustomResourceDefinitions, Statefulsets, and secrets into new or existing namespaces. Perform operations as a user that has broad permissions to create resources within multiple namespaces. Install the AIStor Operator This section installs the OpenShift-certified AIStor Operator. You must complete this section before proceeding to deploying AIStor.

Site replication configures multiple independent AIStor deployments as a cluster of replicas called peer sites. Site replication assumes the use of either the included AIStor identity provider (IDP) or an external IDP. All configured deployments must use the same IDP. Deployments using an external IDP must use the same configuration across sites. AIStor does not recommend using macOS, Windows, or non-orchestrated containerized deployments for site replication except for early development, evaluation, or general experimentation.

This page explains how to deploy AIStor with KES for Server Side Encryption. For instructions on running KES, see the KES docs. Broadly, the required steps are: Create a new external key (EK) for server-side encryption (SSE). Create or modify an AIStor deployment to support SSE with KES. Configure automatic bucket-default SSE. Enabling SSE on an AIStor deployment automatically encrypts the backend data for that deployment using the default encryption key.

The procedure on this page creates a new object lifecycle management rule that transition objects from an AIStor bucket to a remote storage tier on the storage backend. This procedure supports use cases like moving aged data to low-cost public cloud storage solutions after a certain time period or calendar date. Requirements Install and configure mc This procedure uses mc for performing operations on the AIStor cluster. Install mc on a machine with network access to both source and destination clusters. See the mc Installation Quickstart for instructions on downloading and installing mc.

AIStor implements Transport Layer Security (TLS) 1.2+ encryption with support for Server Name Indication (SNI) for selecting relevant TLS certificates in response to client requests. AIStor supports two types of certificate management: Automatic TLS certificate provisioning (default) User-provided TLS certificates When deploying an AIStor object store resource, the CRD definition provides a certificates field for controlling certificate generation and behavior. This field is also available in the object store Helm chart.

Deployment Checklists The following checklists provide a high-level guideline for validating production-readiness of AIStor Servers. These checklists may not meet the precise requirements of your unique deployment topology or architecture, and are intended as a best-effort guide to reliable production deployments.

The following procedure adds a server pool to an existing AIStor deployment running on Kubernetes infrastructure. Each pool expands the total available storage capacity of the cluster while maintaining the overall availability of the cluster. All commands provided below use example values. Replace these values with those appropriate for your deployment. Retrieve and review the existing object store Helm chart. The objectStore.pools key describes the current deployment topology and pool configuration. Each element in the pools array describes a single server pool in the AIStor deployment.

The AIStor Security Token Service (STS) APIs allow applications to generate temporary credentials for accessing the AIStor Server. The STS API is required for AIStor Servers configured to use external identity managers, as the API allows conversion of the external IDP credentials into AWS Signature v4-compatible credentials. STS API endpoints AIStor supports the following STS API endpoints: