##
We are going to make the following changes to the Object Store docs as
part of a larger QC/Content pass:
### Left Navigation
We want to modify the left navigation flow to be a natural progression
from a basic setup to more advanced.
For example:
- Core Concepts
- Deployment Architecture
- Availability and Resiliency
- Erasure Coding and Object Healing
- Object Scanner
- Site Replication and Failover
- Thresholds and Limits
- Installation
- Deployment Checklist
- Deploy MinIO on Kubernetes
- Deploy MinIO on Red Hat Linux
- Deploy MinIO on Ubuntu Linux
- Deploy MinIO for Development (MacOS, Windows, Container)
- Security and Encryption (Conceptual Overview)
- Network Encryption (TLS) (Conceptual overview)
- Enable Network Encryption using Single Domain
- Enable Network Encryption using Multiple Domains
- Enable Network Encryption using certmanager (Kubernetes only)
- Data Encryption (SSE) (Conceptual overview)
- Enable SSE using AIStor Key Management Server
- Enable SSE using KES (Summary page + linkouts)
- External Identity Management (Conceptual Overview)
- Enable External Identity management using OpenID
- Enable External Identity management using AD/LDAP
- Backup and Recovery
- Create a Multi-Site Replication Configuration
- Recovery after Hardware Failure
- Recover after drive failure
- Recover after node failure
- Recover after site failure
- Monitoring and Alerts
- Metrics and Alerting (v3 reference)
- Monitoring and Alerting using Prometheus
- Monitoring and Alerting using InfluxDB
- Monitoring and Alerting using Grafana
- Metrics V2 Reference
- Publish Server and Audit Logs to External Services
- MinIO Healthcheck API
The Administration, Developer, and Reference sections will remain as-is
for now.
http://192.241.195.202:9000/staging/singleplat/mindocs/index.html
# Goals
Maintaining multiple platforms is getting to be too much, and based on
analytics the actual number of users taking advantage of it is minimal.
Furthermore, the majority of traffic is to installation pages.
Therefore we're going to try to collapse back into a single MinIO Object
Storage product, and use simple navigation and on-page selectors to
handle Baremetal vs Kubernetes.
This may also help to eventually stage us to migrate to Hugo + Markdown
---------
Co-authored-by: Daryl White <53910321+djwfyi@users.noreply.github.com>
Co-authored-by: Rushan <rushenn@minio.io>
Co-authored-by: rushenn <rushenn123@gmail.com>
6.2 KiB
Configure MinIO for Authentication using OpenID
minio
Table of Contents
Overview
MinIO supports using an OpenID Connect (OIDC) compatible IDentity Provider (IDP) such as Okta, KeyCloak, Dex, Google, or Facebook for external management of user identities.
This page has procedures for configuring OIDC for MinIO deployments in Kubernetes and Baremetal infrastructures.
This procedure covers:
- Configuring a MinIO cluster for an external OIDC provider.
- Using the MinIO
AssumeRoleWithWebIdentitySecurity Token Service (STS) API to generate temporary credentials for use by applications.
This procedure is generic for OIDC compatible providers. Defer to the documentation for the OIDC provider of your choice for specific instructions or procedures on authentication and JWT retrieval.
Prerequisites
OpenID-Connect (OIDC) Compatible IDentity Provider
This procedure assumes an existing OIDC provider such as Okta, KeyCloak, Dex, Google, or Facebook. Instructions on configuring these services are out of scope for this procedure.
The MinIO cluster must have bidirectional access to the OIDC provider.
Review Access Management Behavior
Ensure each user identity intended for use with MinIO has the
appropriate claim <minio-external-identity-management-openid-access-control>
configured such that MinIO can associate a policy <minio-policy>
to the authenticated user. An OpenID user with no assigned policy has no
permission to access any action or resource on the MinIO cluster.
For JWT claim-based authentication, MinIO only supports OIDC flows using the OpenID Authorization Code Flow.
Access to MinIO Cluster
This procedure uses mc for performing operations on the MinIO cluster.
Install mc on a machine with network access to the cluster.
See the mc Installation Quickstart <mc-install> for
instructions on downloading and installing mc. This
procedure assumes a configured alias <mc alias> for the MinIO cluster.
Configure MinIO with OpenID External Identity Management
Create a new OpenID Configuration
Use the
mc idp openid addcommand to create a new OIDC configuration for the MinIO cluster. The following example command assumes using the JWT claims returned by the OIDC provider forauthorization through policy assignment <minio-external-identity-management-openid-access-control>.mc idp openid add ALIAS \ client_id=minio-oidc-client-id \ client_secret=minio-oidc-client-secret \ config_url="https://openid-provider.example.net/REALM/.well-known/openid-configuration" \ claim_name="minio-policies" \ scopes="openid,groups"You can also configure
RoleArn-based functionality where all authenticated users have a single policy dictated by therole_policysetting. For example, setrole_policy="readOnly"to assign all authenicated users the built-in read-only policy.Review the MinIO Server logs
The MinIO process restarts as part of the new configuration. Examine the logs to ensure the OIDC configuration persisted successfully.
If configuring
role_policyfor one or more configurations, the output includes an ARN for use with the STS API.Generate S3-Compatible Temporary Credentials using OIDC Credentials
MinIO requires clients authenticate using
AWS Signature Version 4 protocol <sig-v4-authenticating-requests.html>with support for the deprecated Signature Version 2 protocol. Specifically, clients must present a valid access key and secret key to access any S3 or MinIO administrative API, such asPUT,GET, andDELETEoperations.Applications can generate temporary access credentials as-needed using the
minio-sts-assumerolewithwebidentitySecurity Token Service (STS) API endpoint and the JSON Web Token (JWT) returned by theOIDC (OpenID Connect)provider.The application must provide a workflow for logging into the
OIDC (OpenID Connect)provider and retrieving the JSON Web Token (JWT) associated to the authentication session. Defer to the provider documentation for obtaining and parsing the JWT token after successful authentication. MinIO provides an example Go applicationweb-identity.go <minio/blob/master/docs/sts/web-identity.go>with an example of managing this workflow.Once the application retrieves the JWT token, use the
AssumeRoleWithWebIdentityendpoint to generate the temporary credentials:POST https://minio.example.net?Action=AssumeRoleWithWebIdentity &WebIdentityToken=TOKEN &Version=2011-06-15 &DurationSeconds=86400 &Policy=PolicyReplace the
TOKENwith the JWT token returned in the previous step.Replace the
DurationSecondswith the duration in seconds until the temporary credentials expire. The example above specifies a period of86400seconds, or 24 hours.Replace the
Policywith an inline URL-encoded JSONpolicy <minio-policy>that further restricts the permissions associated to the temporary credentials.Omit to use the policy associated to the OpenID user
policy claim <minio-external-identity-management-openid-access-control>.
You can optionally include the
RoleArnparameter with the ARN string of your preferred single-policy OIDC configuration.The API response consists of an XML document containing the access key, secret key, session token, and expiration date. Applications can use the access key and secret key to access and perform operations on MinIO.
See the
minio-sts-assumerolewithwebidentityfor reference documentation.