A Firewall Designed for Data: MinIO Firewall

While there are many firewalls out there, they generally fall into two categories: IP-based firewalls and application firewalls. IP-based firewalls, operating at Layer 3 & 4 are simple, lightweight and fairly primitive. They make decisions based on IP addresses and port numbers to permit or block network traffic. Application firewalls, on the other hand, operate at Layer 7 and primarily deal with web traffic, making decisions based on the contents of communication in the web application to permit or block network traffic.

They have their job and the best do them quite well. 

Neither IP-based firewalls nor application firewalls are designed for data. That is why we built MinIO Firewall – because in the modern enterprise, data is what must be protected and an S3-aware firewall doesn’t exist. 

MinIO Firewall is designed specifically to work with applications using MinIO object store and its API endpoints. MinIO Firewall is lightweight, powerful, flexible and extensible. It is managed directly from the AIStor Global Console and supports:

• Bandwidth throttling by Rx/Tx and throttling by Requests rate
• Load balance across MinIO servers
• Liveness port monitoring for high availability
• Support health check for load balancer at separate port
• Support for S3, SFTP and console endpoints
• Auto-TLS, Let’s Encrypt support

We recommend everyone use the Global Console for configuration. It allows the user to configure one or all of your MinIO instances with whatever rules you choose. The Global Console will even allow for the upload of a YAML file if that is required.

You can configure the TLS certificates, ports for S3, Console, SFTP and Health check ports, along with the endpoints for the MinIO Object Store and more using the Global Console.

MinIO Firewall rules can be configured to apply to all buckets or specific object prefixes. Rules can be configured to allow or deny access to buckets, restrict bandwidth and request rate limits. Remember, the MinIO Object Storage Firewall is S3 API aware so there is remarkable flexibility in rule creation. One can even tighten IAM policies, but not loosen, since it operates at the data layer. This includes everything from DELETEs, the # of GET calls, how much, how often, how anonymous requests are dealt with, etc. 

A bucket or prefix-specific rule has precedence over a wildcard rule "*". If a bucket-specific rule is not specified for a particular API, the wildcard rule is applied, if specified. In other words, the rules get evaluated in order of most specific prefix to the least specific prefix.

Let’s take a couple of examples to get a better understanding of this.

In the below example, for objects in bucket mybucket1, the download and upload rate is throttled at 10MB/s with requests to s3.PutObject capped at 10 requests/sec.

The following rule throttles mybucket1 as well as all other buckets s3.GetObject requests to 100 requests/sec. This is because there is no specific rule in bucket: "mybucket*" for s3.GetObject so the wildcard rule "*" applies to mybucket1 as well.

But the  downloadRatePerSec and uploadRatePerSec will not apply to mybucket1 since the above rule takes precedence because it's more specific.

MinIO Firewall rule to deny all requests to myprefix prefix in mybucket bucket

MinIO Firewall rule to restrict upload and download bandwidth to 4MiB for mybucket bucket

Finally, we have the anonymous rule.

Any rule that does not match specifically for any of the prefixes will default to the anonymous rule. But even this could also be overridden for all (or specific) buckets as follows:

POP QUIZ!!!

I know, I hated these too back in high school, but I promise this one is very easy, or else it's on me for not explaining it well enough 😀.

If you had 2 buckets, mybucket809 and yourbucket901, using the rules below, what would be the rate of throttling for s3.ListObjectsV2 API call? Please note API's not specified in MinIO Firewall rules are allowed by default.

Highlight below to find out the answer

Was your answer correct?

Final Thoughts

As you can see that was an easy pop quiz because I did such a wonderful job of explaining the rules in detail 😁. But seriously, please go through the rules to ensure you have a good understanding of them and how they are prioritized.

The beauty of MinIO Firewall is that it's not only very easy to get up and running, which follows our ethos for any product we build, but also the simplicity of the rules. Gone are the days of complex IPtables policies that you cannot make heads or tails of. MinIO Firewall makes it simple by focusing on the rules that are needed for object store and its API calls. It is optimized to ensure there are no latency or unforeseen rules blocking access to your MinIO object store. Moreover, MinIO Firewall is fully supported by our awesome team at SUBNET where we can help you by architecting MinIO Firewall the right way to work with MinIO object store and troubleshoot any future issues.

So what are you waiting for? If you have any questions on MinIO Firewall be sure to reach out to us on Slack or hello@min.io!