Scalable Identity and Access
Management from MinIO

Identity

In the object storage world, users don't log into datastores - applications do. Accordingly, MinIO IAM is built to support both manual (static) and programmatic (dynamic) application-focused identity management. For manual identity creation, customers can use the MinIO Console. For programmatic identity creation, customers can use MinIO’s `mc` command line interface.

MinIO supports an internal identity management functionality. When using MinIO's internal management, the creation of a new user identity follows the access key and secret key credential framework. Applications will use those credentials to authenticate every time they perform operations on the MinIO cluster. MinIO recommends creating one user per application to mitigate the security risk associated with leaked long-lived user credentials by leveraging the mechanisms of user authentication and identity management. MinIO does not limit the number of users that can be managed and the number of users has negligible impact on system performance.

MinIO also supports leading third-party external identity providers (IDP). These standalone systems specialize in the creation, authentication, and management of user identities. Supported IDPs include:

OpenID (OIDC)-compatible providers

When using external IDPs, applications must use the MinIO Secure Token Service (STS) API to provision self-expiring user credentials. While the application needs to implement the STS API to access this functionality, once implemented, the application can access MinIO relying entirely on the external IDP for authentication. Furthermore, the self-expiring credentials generated by STS mitigate the security risks associated with leaked long-lived user credentials.

In addition to internal and external user identities, the MinIO Console supports the creation of Service Accounts. Service accounts are simple identities consisting of an automatically generated access key and secret key. A service account is linked to the user account that created it.

An authenticated user can generate any number of child service accounts, each of which derive their permissions from the parent user. The parent user can further restrict service account permissions during account creation. Service accounts work with both MinIO’s internal and supported external identity management systems. For external IDPs, service accounts may simplify the workflow of provisioning new credentials for an application by enabling the administrator or application owner to log into the MinIO Console with their external credentials and provision the necessary service account credentials for their various applications.

Access Management

Authenticating the identity of an application is only half the battle of securing access to your datastores. The other is setting strict controls and guidelines over the operations and resources to which that application has access. MinIO Access Management controls the authorization of an authenticated application, using AWS IAM-compatible Policy-Based Access Control (PBAC).

Each policy is a list of rules that define the exact resources and operations that are allowed or denied. MinIO uses deny-by-default behavior, decreasing the potential for exposure due to error, so a given policy only needs to describe the minimum set of allowed actions and resources. Policies are granular down to a single action or resource - such as allowing only GET operations on a specific bucket or even on a bucket prefix.

Each user identity can have one explicitly assigned policy. MinIO also supports the creation of groups. Each group has an assigned policy, and all users with membership in that group inherit that policy. A given user's full set of permissions is the combination of its explicitly assigned and inherited policies. Deny rules always override allow rules, so even if a group provides broad allow permissions, the user's explicitly assigned deny policy will override those inherited permissions.

MinIO Access Management provides no paths for privilege escalation - the application gets only what the administrator or app owner has allowed, either through the explicitly assigned user policy or the inherited group policies. For applications using the STS API to authenticate using an external identity provider, the STS API allows for additional reductions to policy scope. Similarly, service accounts allow for restricted privileges on top of those inherited from their parent user.