Closes #639 Closes #635 Partially Addresses #590 - MINIO #16026 https://github.com/minio/minio/pull/16026 - MINIO #16044 https://github.com/minio/minio/pull/16044 - MINIO #16035 https://github.com/minio/minio/pull/16035 - CONSOLE #2428 https://github.com/minio/console/pull/2428 Other Fixes: - Removes admonition about IDP interactions (multi-IDP support) - Update Console screenshots and overview page to cover layout changes - Partial fix for DOCS #590 (Policy now under Identity section)
6.5 KiB
User Management
minio
Table of Contents
Overview
A MinIO user consists of a unique access key (username) and corresponding secret key (password). Clients must authenticate their identity by specifying both a valid access key (username) and the corresponding secret key (password) of an existing MinIO user.
Each user can have one or more assigned policies <minio-policy>
that explicitly list the actions and resources to which that user has
access. Users can also inherit policies from the groups <minio-groups>
in which they have membership.
MinIO by default denies access to all actions or resources not
explicitly allowed by a user's assigned or inherited policies <minio-policy>. You must either
explicitly assign a policy <minio-policy> describing the user's
authorized actions and resources or assign the user to groups
<minio-groups> which have associated policies. See minio-access-management for
more information.
This page documents user management for the MinIO internal IDentity Provider (IDP). MinIO also external management of identities using either an OpenID Connect (OIDC) or Active Directory/LDAP IDentity Provider (IDP). For more information, see:
minio-external-identity-management-openidminio-external-identity-management-ad-ldap
Enabling external identity management disables the MinIO internal
IDP, with the exception of creating access keys
<minio-idp-service-account>.
Access Keys
MinIO Access Keys (formerly "Service Accounts") are child identities
of an authenticated MinIO user, including externally managed identities <minio-authentication-and-identity-management>.
Each access key inherits its privileges based on the policies <minio-policy>
attached to it's parent user or those groups in which the
parent user has membership. Access keys also support an optional inline
policy which further restricts access to a subset of actions and
resources available to the parent user.
A MinIO user can generate any number of access keys. This allows application owners to generate arbitrary access keys for their applications without requiring action from the MinIO administrators. Since the generated access keys have the same or fewer permissions as the parents, administrators can focus on managing the top-level parent users without micro-managing generated access keys.
You can create access keys using either the MinIO Console <minio-console-user-access-keys>
or by using the mc admin user svcacct add command.
Access Keys are for Programmatic Access
Access Keys support programmatic access by applications. You cannot use an access key to log into the MinIO Console.
MinIO root User
MinIO deployments have a root user with access to all
actions and resources on the deployment, regardless of the configured
identity manager
<minio-authentication-and-identity-management>. When a
minio server first
starts, it sets the root user credentials by checking the
value of the following environment variables:
MINIO_ROOT_USERMINIO_ROOT_PASSWORD
Rotating the root user credentials requires updating either or both
variables for all MinIO servers in the deployment. Specify long,
unique, and random strings for root credentials. Exercise all
possible precautions in storing the access key and secret key, such that
only known and trusted individuals who require superuser access
to the deployment can retrieve the root credentials.
- MinIO strongly discourages using the
rootuser for regular client access regardless of the environment (development, staging, or production). - MinIO strongly recommends creating users such that each client has access to the minimal set of actions and resources required to perform their assigned workloads.
If these variables are unset, minio defaults to minioadmin and
minioadmin as the access key and secret key respectively.
MinIO strongly discourages use of the default credentials
regardless of deployment environment.
Deprecation of Legacy Root User Environment Variables
MinIO RELEASE.2021-04-22T15-44-28Z and later
deprecates the following variables used for setting or updating root
user credentials:
MINIO_ACCESS_KEYto the new access key.MINIO_SECRET_KEYto the new secret key.MINIO_ACCESS_KEY_OLDto the old access key.MINIO_SECRET_KEY_OLDto the old secret key.
User Management
Create a User
Use the mc admin user add command to create a new user on
the MinIO deployment:
mc admin user add ALIAS ACCESSKEY SECRETKEY
- Replace
ALIAS <mc admin user add TARGET>with thealias <mc alias>of the MinIO deployment. - Replace
ACCESSKEY <mc admin user add ACCESSKEY>with the access key for the user. MinIO allows retrieving the access key after user creation through themc admin user infocommand. - Replace
SECRETKEY <mc admin user add SECRETKEY>with the secret key for the user. MinIO does not provide any method for retrieving the secret key once set.
Specify a unique, random, and long string for both the
ACCESSKEY and SECRETKEY. Your organization may
have specific internal or regulatory requirements around generating
values for use with access or secret keys.
After creating the user, use mc admin policy set to associate a MinIO Policy Based Access Control <minio-policy>
to the new user. The following command assigns the built-in readwrite policy:
mc admin policy set ALIAS readwrite user=USERNAME
Replace USERNAME with the ACCESSKEY created
in the previous step.
Delete a User
Use the mc admin user remove command to remove a user on a
MinIO deployment:
mc admin user remove ALIAS USERNAME
- Replace
ALIAS <mc admin user remove TARGET>with thealias <mc alias>of the MinIO deployment. - Replace
USERNAME <mc admin user remove USERNAME>with the name of the user to remove.