Preventing Vendor Lock-in: Your Thoughts on IronBucket (New OSS Project)

[ZiggiZagga]

Hi all,

I’m just getting started on a new project called 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] [2] [3]. 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 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

[ZiggiZagga]

Why IronBucket matters now — and what comes next

Hi,

Merry Christmas everyone!

Object Storage Governance is becoming increasingly vendor‑controlled and increasingly fragile.

• sudden licensing changes
• features moving behind paywalls
• IAM models that lock users into a single vendor
• governance layers tightly coupled to proprietary APIs

this creates real risks.

• Loss of independence if identity and access control live inside the storage vendor
• Loss of trust when governance rules are opaque or tied to closed systems
• Loss of portability when applications depend on vendor‑specific IAM semantics
• Loss of resilience when a project stops evolving but remains mission‑critical

What I will do next

To make this concrete, I’m preparing a first binary release of IronBucket so the community can actually run it, test it, and tell me where it breaks.

This initial release will focus on:

• a minimal but functional S3‑compatible proxy
• OIDC‑based authentication
• a simple policy engine
• a quickstart environment
• enough documentation to get people experimenting

Open for feedback.