AIStor Server includes three groups of environment variables to manage how the server interacts with the AIStor Key Management Service (KMS), Key Encryption Service (KES), or static key files. You may only define one of the three sets, where defining more that one group results in errors and failure to start. Each configuration setting controls fundamental AIStor behavior and functionality. Test configuration changes in a lower environment, such as DEV or QA, before applying to production. Define any one set of these environment variables in the host system prior to starting or restarting the AIStor process. Refer to your operating system’s documentation for how to define an environment variable.

This page documents settings for enabling external identity management using an OpenID Connect (OIDC)-compatible provider. See OpenID Connect Access Management for a tutorial on using these settings. You can establish or modify settings by defining: an environment variable on the host system prior to starting or restarting the AIStor Server. Refer to your operating system’s documentation for how to define an environment variable. a configuration setting using mc admin config set. If you define both an environment variable and the similar configuration setting, AIStor uses the environment variable value.

Developers

This page explains how to deploy AIStor with KES for Server Side Encryption. For instructions on running KES, see the KES docs. Enabling SSE on an AIStor deployment automatically encrypts the backend data for that deployment using the default encryption key. AIStor requires access to KES and the external KMS to decrypt the backend and start normally. The KMS must maintain access to the MINIO_KMS_KES_KEY_NAME. You cannot disable or reset encryption of the backend.

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. AIStor includes support for deploying AIStor Key Manager as a dedicated root Key Management Service (KMS) with direct integration. Key Manager provides equivalent functionality to other third-party KMS solutions for managing root/external encryption keys in support of encryption operations.

This section documents steps for installing and managing AIStor Server on macOS™ host machines. Procedure Install AIStor Server onto the macOS host The easiest way to install AIStor Server on macOS is using Homebrew. Alternatively, AIStor provides binaries for M-series processors (ARM64) and older Intel-based processors (AMD64). Download the binary, set it as executable, and copy it to a location in your $PATH such as /usr/local/bin

MinIO AIStor Documentation MinIO AIStor is a high-performance S3-compatible object store licensed under the MinIO Com...

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. AIStor supports the following types of certificate signatures: self-signed internal or private certificate authorities (CAs) third-party CAs Multiple certificates are implemented with Server Name Indication (SNI) to determine which certificate to return to a client based on the hostname in the request.

AIStor supports deploying resources onto Kubernetes infrastructure through our first-party operator model. AIStor also provides a Red Hat OpenShift certified operator. Setting up AIStor on Kubernetes involves three steps: Installing AIStor Setting up network encryption Setting up server-side encryption Kubernetes API Support Production Kubernetes infrastructure should run currently supported releases of the Kubernetes API.

AIStor requires authentication and authorization for every operation on the object store. Human users and client applications must authenticate, and can perform only operations on resources explicitly allowed by the access policies assigned to them. Authentication verifies the identity of a user or client application. User credentials take the form of a username and password. Application credentials can take the form of an access key and secret key, or an application can call the appropriate STS endpoint. Which endpoint depends on your identity provider.