Identity and Access Management

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.

Authorization defines the actions an authenticated user or application can perform, and the resources they can access. AIStor implements policy-based access control (PBAC), in which a policy consists of one or more rules that define specific access permissions. By default, AIStor denies access to any action or resource that is not explicitly granted by an assigned policy. A user with no explicitly assigned or inherited policies cannot perform any S3 or AIStor administrative API operations.

AIStor provides a built-in identity manager. You can also enable identity management using one of the following external providers:

• OpenID Connect (OIDC)

• Active Directory/LDAP

• Your custom identity provider, with the AIStor authentication plulgin and authorization plugin extensions

Human users are typically identified with a username and password, regardless of the identity provider.

For application access only, you can create access keys (formerly known as service accounts). An access key is a child identity of an AIStor user, and inherits its access rights from the policies assigned to its parent user. You can also assign an additional inline policy to an access key account to further restrict acccess.

You can create access keys with mc or the console even if you manage your users with an external identity provider.

For short-lived application access, you can call the endpoint of the Security Token Service (STS) API that’s supported by your identity provider. For more information, see individual pages for configuring identity providers, and the STS reference documentation.

The AIStor root user has access to all actions and resources on the deployment. This user is created when the deployment first starts. You set the username and password for the root user with environment variables (default value for each minioadmin):

• MINIO_ROOT_USER
• MINIO_ROOT_PASSWORD

Consider implementing the following best practices for managing your root user account:

• Specify long, unique, and random strings for root credentials.

• Make sure that only known and trusted individuals who require superuser access can retrieve these credentials.

• Do not use these credentials for regular client access, whether the environment is production or not

AIStor implements Policy-Based Access Control (PBAC) to define the authorized actions and resources to which an authenticated user or application has access. Each policy describes one or more actions and conditions that outline the permissions of a user or group of users.

Depending on your choice of identity provider, you can assign policies to individual users or to groups of users.

If you work with the built-in identity manager or with Active Directory/LDAP, you can assign policies to users or to groups. If you work with an OIDC provider, you can assign policies only to a user’s policy claim.

AIStor PBAC is built for compatibility with AWS IAM policy syntax, structure, and behavior. For details, see Access Control with Policy Management. This documentation covers AIStor IAM, but see also the AWS documentation for IAM.