MinIO 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. You must set up TLS before you can enable data encryption, also called server-side encryption. MinIO AIStor supports the following types of certificate signatures: self-signed internal or private certificate authorities (CAs) third-party CAs Multiple certificates are implemented with SNI to determine which certificate to return to a client based on the hostname in the request.

This procedure explains how to specify the TLS certificates your MinIO AIStor deployment requires and configure your deployment to work with the certificates. See also Enable Network Encryption for explanations of how MinIO AIStor requires TLS and which cipher suites MinIO AIStor supports. Prerequisites The appropriate X.509 certificates for your environment.

Server-Side Encryption (SSE) protects objects as part of write operations, allowing clients to take advantage of server processing power to secure objects at the storage layer (encryption-at-rest). SSE also provides key functionality for regulatory and compliance requirements around secure locking and erasure. MinIO AIStor includes support for deploying MinIO KMS as a dedicated root Key Management Service (KMS) with direct integration. MinIO KMS provides equivalent functionality to other third-party KMS solutions for managing root/external encryption keys in support of encryption operations.

This guide covers configuring Microsoft Entra ID (formerly Azure Active Directory) as an OpenID Connect (OIDC) identity provider for MinIO AIStor. For general OIDC configuration, see OpenID Connect Identity Management. Prerequisites An active Azure subscription with access to the Azure Portal. A MinIO AIStor deployment with network connectivity to Microsoft identity endpoints. The mc CLI installed and configured with an alias for your MinIO AIStor deployment. Microsoft Graph API permissions MinIO AIStor uses the Microsoft Graph API to query group memberships for authenticated users. The following Application permissions are required (not Delegated):

MinIO AIStor server-side bucket replication is an automatic bucket-level configuration that synchronizes objects between a source and destination bucket. MinIO AIStor server-side replication requires the source and destination bucket be two separate MinIO AIStor clusters running the same Object Store version. For each write operation to the bucket, MinIO AIStor checks all configured replication rules for the bucket and applies the matching rule with highest configured priority. MinIO AIStor synchronizes new objects and object mutations, such as new object versions or changes to object metadata. This includes metadata operations such as enabling or modifying object locking or retention settings.

MinIO AIStor supports publishing bucket notification events to a Kafka service endpoint. MinIO AIStor relies on the https://github.com/Shopify/sarama project for Kafka connectivity and shares that project’s Kafka support. See the sarama Compatibility and API stability section for more details. Prerequisites Kafka minimum versions and supported versions.

The procedure on this page creates a new bucket replication rule for two-way “active-active” synchronization of objects between MinIO AIStor buckets. Requirements Replication requires all participating clusters meet the bucket replication requirements. This procedure assumes you have reviewed and validated those requirements.

You can use the MinIO AIStor Console to perform many of the deployment monitoring and management functions available in MinIO AIStor, such as: License to monitor the status and expiration of the MinIO Software License used for the MinIO AIStor deployment. Monitor the health and activity of the deployment by reviewing metrics, server or audit logs, trace history, S3 events, or drive health. Configure alerts by adding or managing a notification target. Set up site replication to synchronize datacenters for timely access across geographically dispersed workforces or for disaster preparedness. Configure deployment settings. Overview The Overview page displays summary information for a deployment including:

AIStor Server publishes cluster and node metrics using the Prometheus Data Model. You can use any scraping tool to pull metrics data from AIStor Server for further analysis and alerting. This page provides guidance on baseline P0 and P1 alerts for use with building alerting rules and infrastructure around the available V2 or V3 metrics. These alerts assume infrastructure similar to or exceeding our reference hardware guidelines. Modify them to reflect your needs or open a SUBNET issue for further guidance.

Best-effort enforcement Bucket quota enforcement is best-effort and not real-time. MinIO AIStor evaluates quota usage periodically through its internal scanner, so a bucket may temporarily exceed its configured quota between scanner cycles. Do not rely on bucket quotas as a hard ceiling for safety-critical storage limits. MinIO AIStor supports setting hard quotas on buckets to limit the total amount of data a bucket can store. When a bucket reaches its configured quota, MinIO AIStor rejects further write operations to that bucket until data is removed to bring usage below the limit.