Welcome to the upcoming version of the MinIO Documentation! The content of these pages may change at any time. If you can't find what you're looking for, check our legacy documentation. Thank you for your patience.

Configure Tenant Security

Identity and Access Management

MinIO enforces authentication and authorization for all incoming requests. Administrators can use the MinIO Console or an S3-compatible command-line tool such as mc for configuring IAM on a MinIO Tenant.

These pages document MinIO IAM in context of MinIO Tenants on Kubernetes. See Identity and Access Management for more complete documentation.

Identity Management

A MinIO user is an identity that includes at minimum credentials consisting of an Access Key and Secret Key. MinIO requires all incoming requests include credentials which match an existing user.

If MinIO successfully authenticates an incoming request against either an internally-managed or externally-managed identity, MinIO then checks if the identity is authorized to make the request. See Access Management for more information on authorization.

MinIO by default supports creating and managing users directly on the MinIO Tenant. MinIO also supports configuring an External IDentity Providers (IDP), such as Active Directory or OpenID, where MinIO can look up identities managed by the external IDP as part of authentication. See Operator Examples for examples implementations.

See User Management for tutorials on using the MinIO Console for performing user management on the MinIO Tenant. The following list includes common identity management procedures:

See MinIO Users for more complete documentation on MinIO Users.

Access Management

After MinIO authenticates a user, MinIO checks whether the specified user is authorized to perform the requested operation. MinIO uses Policy-Based Access Control (PBAC) for defining the actions and resources to which a client has access.

MinIO policies are JSON documents with IAM-compatible syntax. Each MinIO user can have one attached policy for defining its scope of access. MinIO also supports creating groups of users, where the users inherit the policy attached to the group. A group can have one attached policy for defining the scope of access of its membership.

A given user’s access therefore consists of the set of both its explicitly attached policy and all inherited policies from its group membership. MinIO only processes the requested operation if the user’s complete set of policies explicitly allow access to both the required actions and resources for that operation.

MinIO PBAC is deny-by-default, where MinIO denies access to any action or resource not explicitly allowed by the user’s attached or inherited policies. MinIO also prioritizes Deny rules if two or more policies conflict over access to a given action or resource.

See Group Management and Policy Management for tutorials on using the MinIO Console for performing group and policy management respectively. The following list includes common access management procedures:

See MinIO Groups and MinIO Policies for more complete documentation on MinIO Groups and Policies.

Encryption and Key Management

Network Encryption

MinIO supports configuring TLS for encrypting data transmitted across the network. The MinIO Operator automatically generates TLS x.509 certificates using the Kubernetes certificates.k8s.io API. The Kubernetes TLS API uses the Certificate Authority (CA) specified during cluster bootstrapping when approving a Certificate Signing Request (CSR) issued through the API. The MinIO Operator generates a certificate for each of the following domains:

*.minio-hl.namespace.svc.cluster.local

Matches the hostname of each MinIO Pod in the Tenant.

minio-hl.namespace.svc.cluster.local

Matches the headless service corresponding to all MinIO Pods in the Tenant.

minio.namespace.cluster.local

Matches the service corresponding to the MinIO Tenant. Kubernetes pods typically use this service when performing operations against the MinIO Tenant.

minio-console-svc.namespace.cluster.local

Matches the service corresponding to all MinIO Console pods in the Tenant.

*.minio-kes-hl-svc.namespace.svc.cluster.local

Matches the hostname of each MinIO KES Pod in the Tenant.

minio-kes-hl-svc.namespace.svc.cluster.local

Matches the headless service corresponding to all MinIO KES Pods in the Tenant.

Note

The namespace and cluster.local fields will differ depending on the Kubernetes Namespace in which the MinIO Tenant is deployed and the Kubernetes cluster DNS settings.

Kubernetes pods by default do not automatically trust certificates generated through the Kubernetes TLS API. For applications internal to the Kubernetes cluster (i.e. applications running on Pods in the cluster), you can manually add the Kubernetes CA to the Pod’s system trust store using the update-ca-certificates utility:

cp /var/run/secrets/kubernetes.io/serviceaccount/ca.crt /usr/local/share/ca-certificates/
update-ca-certificates

For applications external to the Kubernetes cluster, you must configure the appropriate Ingress resource to route traffic to the MinIO Tenant. The requirements for fully validated TLS connectivity depend on the specific Ingress configuration. Ingress configuration is out of scope for this documentation. See Kubernetes Ingress for more complete guidance.

The MinIO Operator also supports deploying MinIO Tenants with user-generated x.509 TLS certificates and Certificate Authorities (CA). MinIO supports the Server Name Indication (SNI) extension and allows Administrators to specify multiple custom TLS certificates for supporting HTTPS access to the Tenant through multiple domains. See User-Generated TLS Certificates for MinIO Object Storage for more information.

Object Encryption

MinIO Tenants support Server-Side Encryption (SSE-S3) of objects using an external Key Management Service (KMS) such as Hashicorp Vault, Thales CipherTrust (formerly Gemalto Keysecure), and Amazon KMS.

See the MinIO Operator Examples for guidance on creating MinIO Tenant object specifications with support for SSE-S3.