Table of Contents
New in version Operator: v5.0.0
The MinIO Operator supports a set of API calls that allows an application to obtain STS credentials for a MinIO Tenant.
Benefits of STS for MinIO Operator include:
STS credentials allow an application to access objects on a MinIO Tenant without the need to create credentials for the application on the tenant.
Allows applications to access objects in MinIO tenants using a Kubernetes-native authentication mechanism.
Implementing STS for MinIO Operator allows you to utilize infrastructure as code principles and configuration by using the tenant custom resource definition (CRD) and a MinIO PolicyBinding CRD.
MinIO Operator launches with STS disabled by default. To use STS with the Operator, you must first explicitly enable it.
The procedure on this page includes instructions to enable the STS API in the MinIO Operator.
STS for the MinIO Operator requires the following:
Enable STS functionality for the deployment
kubectl -n minio-operator set env deployment/minio-operator OPERATOR_STS_ENABLED=on
minio-operatorwith the namespace for your deployment.
deployment/minio-operatorwith the value for your deployment’s MinIO Operator.
You can find the deployment value by running
kubectl get deployments -n <namespace>, where you replace
<namespace>with the namespace for the MinIO Operator. Your MinIO Operator namespace is typically
minio-operator, though this value can change during install.
Ensure an appropriate policy or policies exist on the MinIO Tenant for the application to use for the application
The next step uses a YAML document to map one or more existing tenant policies to a service account through a custom resource called a
Create YAML resources for the Service Account and Policy Binding:
Apply the YAML file to create the resources on the deployment
kubectl apply -k path/to/yaml/file.yaml
Use an SDK that supports the
AssumeRoleWithWebIdentitylike behavior to send a call from your application to the deployment
The STS API expects a JWT for the service account to exist in the Kubernetes environment. When linked to a pod, such as through a deployment’s
.spec.spec.serviceAccountNamefield, Kubernetes mounts a JWT for the service account from a well-known location, such as
Alternatively, you can define the token path as an environment variable:
The following MinIO SDKs support
For examples of using the SDKs to assume a role, see GitHub.
A Service Account is a Kubernetes resource type that allows an external application to interact with the Kubernetes deployment.
When linked to a pod, such as through a deployment’s
.spec.spec.serviceAccountName field, Kubernetes mounts a JWT for the service account from a well-known location, such as
The following yaml creates a service account called
stsclient-sa for the
apiVersion: v1 kind: ServiceAccount metadata: namespace: sts-client # The namespace to add the service account to. Usually a tenant, but can be any namespace in the deployment. name: stsclient-sa # The name to use for the service account.
PolicyBinding is a MinIO-specific custom resource type for Kubernetes that links an
application to a set of policies.
Create Policy Bindings in the namespace of the tenant they are for.
For the purposes of the MinIO Operator, an application is any requesting resource that identifies with a specific service account and tenant namespace.
PolicyBinding resource links the application to one or more policies for the tenant on that namespace.
The below yaml creates a
PolicyBinding that links an application using the service account
stsclient-sa that exists in the namespace
sts-client to the policy
test-bucket-rw in the target tenant located in the namespace
The policies granted in the yaml definition must already exist on the MinIO Tenant.
apiVersion: sts.min.io/v1alpha1 kind: PolicyBinding metadata: name: binding-1 namespace: minio-tenant-1 # The namespace of the tenant this binding is for spec: application: namespace: sts-client # The namespace that contains the service account for the application serviceaccount: stsclient-sa # The service account to use for the application policies: - test-bucket-rw # A policy that already exists in the tenant # - test-bucket-policy-2 # Add as many policies as needed