Today we want to cover the MinIO best practices with respect to S3 security and access controls.
Least Privilege Access
The least privilege access principle is fundamental to the security of your MinIO deployment. You control which applications access which S3 resource on MinIO. Therefore, you should only grant the permissions that are required for a particular task.
Access to S3 resources is controlled by IAM policies that are attached to the application credentials, in particular the S3 access key. For example, when creating a new access key through the web UI, you can restrict the permissions of the access key by defining an attached IAM policy:
The attached policy shown above only grants read access to the
my-bucket bucket. So, the application using these access credentials can only read but not write to MinIO - and only from this one specific bucket.
Versioning and S3 Object Locks
S3 Object Locking enables you to store objects on MinIO using the write-once-read-many (WORM) model. You can either attach a retention period or legal hold to objects. The former prevents any overwrites until the retention period has expired, while the later disallows overwrites until the legal hold has been removed from the object.
As per the S3 specification, you can enable object locking on a bucket that has versioning turned on.
You can set a retention configuration on the bucket that controls how long the WORM model applies to newly uploaded objects. You can of course always set specific retention policies or legal holds on individual objects. However, a bucket-level default is recommended to ensure that all objects within the bucket are protected from accidental or malicious overwrites.
Versioning and Object Locking are particularly useful to meet the business-critical threats imposed by ransomware attacks. The WORM model prevents ransomware from deleting or encrypting your data and is a important line of defence against cybercrime groups trying to hold your data hostage.
Encryption at Rest
Encrypting your data before saving it prevents data breaches from low-level access to your MinIO storage infrastructure. MinIO supports S3 server-side encryption with externally managed keys.
You can connect the leading on-prem and cloud KMS providers, like Hashicorp Vault or AWS, to your MinIO cluster via our KES project. Your encryption keys remain secure inside the KMS while MinIO can leverage the KMS to encrypt data before it gets persisted.
Therefore, you set up KES to connect to your KMS provider of choice. Then you connect MinIO to KES. For example like shown in your Hashicorp Vault guide.
In your MinIO web UI, you can also set a bucket-level encryption configuration such that any newly uploaded object to the bucket gets encrypted with the specified key at the KMS.
When there is no KMS solution in place, MinIO has you covered. We support a simple built-in KMS that you can use to have encryption enabled from the get go while putting the KMS in place.
You can generate your own random encryption key using basic UNIX commands:
cat /dev/urandom | head -c 32 | base64
MinIO can be configured to encrypt data with your key by setting just one environment variable.
Once your KMS solution is available, you can import this key easily into the KMS.
Encryption in Transit
In addition to encryption at rest, you can enable HTTPS on your MinIO deployment to prevent potential attackers from eavesdropping on your network traffic. MinIO supports only modern TLS 1.2 and 1.3 ciphersuites with zero configuration. All you have to provide is the TLS private key and certificate. Learn more by visiting your TLS and network security documentation.
MinIO has built-in identity and user management. However, when managing a large storage infrastructure for many different application teams, a centralized identity management system like Okta, or LDAP/Active Directory may give a better control over all users and applications.
MinIO has built-in support for LDAP and OpenID Connect identity providers.
When configured, MinIO uses the user identities provided by the identity provider for S3 request authentication. While external identity providers add some complexity to the storage system, they provide the advantage of centralized identity management that reduces the overall complexity for large deployments and help reduce the risk of not deactivating stale accounts.
Cross-site or cross-region data replication is essential to reduce the risk and duration of operational and security incidents. MinIO makes it easy to set up synchronous and asynchronous replication between sites across data centers.
When a site goes down or is under attack, you can fall back to your replicated site(s), either via load balancer rules or DNS configuration. Hence, your storage infrastructure can handle failures of entire sites without impacting client applications.
Like with our openly available source code, we at MinIO handle security incidents transparently. When you run MinIO deployments you should keep an eye on our security advisories. As soon as a new release with a security fix is available we publish a security advisory explaining the impact and mitigations. This helps you identify and patch security risks within your storage infrastructure quickly. When subscribed to our SUBNET support system, you get notifications about new security fixes and you have direct engineering support when assessing the impact of a security issue on your deployments.
In this post we have outlined the security best practices for MinIO deployments. The two main topics you should focus on the most are access control management via IAM policies and enabling encryption at rest as well as inflight. In addition, you should leverage features for data protection against malicious or accidental deletes - provided by the S3 object locking and cross-site data replication.
By following these few best practices, you will put your storage infrastructure and all the applications consuming it on a solid and secure foundation.