Identity and Access Management

MinIO 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. MinIO AIStor implements policy-based access control (PBAC), in which a policy consists of one or more rules that define specific access permissions. By default, MinIO 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 MinIO AIStor administrative API operations.

How AIStor authorizes a request A request arrives from a client. AIStor authenticates it, which the built-in identity provider, an AD or LDAP directory, an OIDC provider, an X.509 or SPIFFE certificate, a Kubernetes service account, or an authentication webhook can answer. AIStor then authorizes it, which its own policy engine or an authorization webhook can answer. The operation then runs, or returns 403. IDENTITY AND ACCESS two steps, and each one has its own extension point CLIENT Request signed or STS AISTOR SERVER your deployment 1 · Authenticate who is making this request? 2 · Authorize is this action allowed? WHAT CAN ANSWER EACH STEP ANSWERS STEP 1 built-in users AD / LDAP OpenID Connect X.509 / SPIFFE certificate Kubernetes service account authentication webhook ANSWERS STEP 2 AIStor policies (PBAC) authorization webhook Allowed · the operation runs Denied · the request returns 403 AIStor denies anything a policy does not explicitly allow, so a user with no policy can perform no operation at all.
Two steps, each with its own extension point. An identity provider answers the first; policy evaluation or an authorization webhook answers the second. Choosing one does not constrain the other.

Identity management

MinIO AIStor supports multiple identity providers for authenticating users and applications:

Provider Description
Built-in Manage users and groups directly within MinIO AIStor
OpenID Connect Integrate with OIDC providers (Okta, Auth0, Keycloak, Google)
Active Directory/LDAP Authenticate against directory services
X.509 certificate Authenticate with a client certificate or SPIFFE SVID
Kubernetes service account Authenticate in-cluster workloads with their service account token
Authentication plugin Implement custom authentication logic

See Identity Management for details on configuring multiple providers.

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

Limited access for applications

For application access only, you can create access keys (formerly known as service accounts). An access key is a child identity of a MinIO 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 access.

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 your identity provider supports. For more information, see individual pages for configuring identity providers, and the STS reference documentation.

Root user

The MinIO 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):

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

Access management

MinIO 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 through the provider’s role_policy setting or through a user’s policy claim.

MinIO 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 MinIO AIStor IAM, but see also the AWS documentation for IAM.

Deny Overrides Allow

MinIO AIStor follows AWS IAM policy evaluation rules. MinIO AIStor evaluates every Deny rule before any Allow rule. A Deny rule overrides an Allow rule when the request matches that rule’s action, resource, and conditions. For example, a user has a policy with an Allow rule for a resource, and a group the user belongs to has a policy with a Deny rule for that same resource. MinIO AIStor applies the Deny rule.

For more information, see the AWS documentation on Policy evaluation logic.