[D] Preventing Vendor Lock-in: Your Thoughts on IronBucket (New OSS Project) [gravitino]

["ZiggiZagga (via GitHub)" <gi...@apache.org>]

GitHub user ZiggiZagga created a discussion: Preventing Vendor Lock-in: Your Thoughts on IronBucket (New OSS Project)

Hi all,

I’m just getting started on a new project called [IronBucket](https://github.com/ZiggiZagga/IronBucket), and I wanted to reach out for feedback from this community since your work has been a major inspiration.

**IronBucket** is a zero-trust, identity-aware proxy that wraps any S3-compatible object store with Git-managed, policy-as-code access control. The idea is to bring together best practices from Project Nessie (Git-style policy branching), Apache Polaris (fine-grained RBAC/ABAC and tag-based enforcement), Unity Catalog (centralized governance and global identity awareness), and Gravitino (metadata governance object modeling for object stores).

**Why am I building this?**  
My main motivation is to avoid vendor lock-in in the modern data ecosystem. For example, MinIO recently removed key management features from its community dashboard and made them available only on paid plans, leaving many open-source users frustrated [[1]](https://blocksandfiles.com/2025/06/19/minio-removes-management-features-from-basic-community-edition-object-storage-code/) [[2]](https://cloudian.com/blog/minios-ui-removal-leaves-organizations-searching-for-alternatives/) [[3]](https://www.futuriom.com/articles/news/minio-faces-fallout-for-stripping-features-from-web-gui/2025/06). Additionally, many of the emerging data catalogs and lakehouse governance solutions (like Unity Catalog and Polaris) are effectively vendor-locked to AWS S3 in their official repositories, which makes the "open" lakehouse a semi-open solution in practice.

Right now, the project is just getting started, and the [README](https://github.com/ZiggiZagga/IronBucket#readme) outlines the vision and some early technical directions. I’d really appreciate feedback, suggestions, or critiques from experienced folks here, especially on:

- Gaps or risks in the approach/architecture
- Policy validation, testing, or dry-run ideas
- Integration points or lessons from your project’s journey

Thanks so much for your work and for any thoughts you can share!

Best,  
ZiggiZagga

GitHub link: https://github.com/apache/gravitino/discussions/7487

----
This is an automatically sent email for dev@gravitino.apache.org.
To unsubscribe, please send an email to: dev-unsubscribe@gravitino.apache.org