A Closer Look: MinIO Firewall

In our previous discussion, we introduced MinIO Firewall, a novel security component that goes beyond traditional network and application security layers. 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. This S3-aware data firewall is crucial for modern data protection, operating at the storage layer to safeguard your data comprehensively. 

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.

Let’s delve into setting up this advanced firewall, designed to secure your data in today’s increasingly complex digital landscape.

Enable and Configure Firewall

Let's use the AIStor Global Console to set up the firewall. Follow the below steps to enable and configure the Firewall.

Configure TLS for Secure Communication

As part of the AIStor Suite, we’ve always recommended to ensure you enable TLS on AIStor so that even inter cluster communications are encrypted. With that same spirit, we support TLS for MinIO Firewall as well. This ensures that any connection to the MinIO Object Store via the Firewall is encrypted end to end. For enhanced security, configure TLS settings when launching the firewall with Let’s Encrypt.

Precedence of Anonymous Rule

In our MinIO Firewall configuration, you’ll encounter two distinct rules for anonymous access:

Global Anonymous Setting: At the start when you enable firewall, we specify a global setting that allows anonymous access across all buckets unless a more specific rule denies it.

Bucket Specific Anonymous: After configuring the global setting, under each individual rules, we can set a more specific rule that overrides the global setting, effectively denying anonymous access

In this case, even though we initially toggled Global Anonymous to Allow for all buckets, because we set another more specific rule below it, which also applies to all buckets, the one we set later takes precedence over the global setting. In other words, anonymous bucket access will be denied for all buckets.

Load Balance across MinIO nodes

As an added bonus, because we need to define all the MinIO nodes as a backend for the Firewall, the Firewall doubles as a LoadBalancer, negating the need for a separate load balancer between the firewall and MinIO nodes.

This eliminates further complexity and ensures there is no single point of failure in case one of the MinIO backend goes offline. Please note, you need to have another level of redundancy to ensure when connecting to MinIO Firewall the incoming connections are also distributed to multiple MinIO Firewall instances. This configuration is beyond the scope of this blog but its something to keep in mind.

Health Checks and Monitoring

The health check enabled you to see if the Firewall is in a healthy state. You can check the health and liveliness as follows.

If everything is Green that will indicate that the firewall is functioning properly.

Final Thoughts

With MinIO Firewall, gone are the days of wrestling with complex IPtables and unclear access policies. Our firewall solution simplifies your security by focusing exclusively on the essential rules required for your object store and API interactions. 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!