IronBucket is a zero-trust, identity-aware proxy that wraps any S3-compatible object store with Git-managed, policy-as-code access control. Enforce fine-grained permissions using OIDC/OAuth2 identity, attribute-based rules, and GitOps-style auditability.
🔐 Secure by default.
🧩 Pluggable with any object store.
🧭 Governed by Git.
| Aspect | Why it matters |
|---|---|
| GitOps-native policy store | Treating access rules like code—branches, PRs, rollbacks—pulls security into the engineering workflow. No more brittle IAM JSON or scattered ACLs. |
| Zero-trust, identity-aware proxy | By terminating OIDC/OAuth at the gateway, IronBucket decouples identity from the store’s own ACL model and provides a unified RBAC/ABAC layer across S3, MinIO, Ceph, etc. |
| Drop-in S3 API compatibility | Keeping the wire protocol untouched means zero rewrites. It works just like Envoy's service mesh adoption playbook. |
| Clear inspiration from proven OSS projects | IronBucket borrows branching from Project Nessie and tag-based enforcement from Polaris—standing on solid OSS shoulders rather than inventing in a vacuum. |
🚧 This project is completely new almost no code is written yet. If you’ve ever wanted to help shape something from day zero, now’s your chance.
Here are some of the toughest, most rewarding problems waiting for builders like you:
| Challenge | Why it matters & how you could help |
|---|---|
| ⚙️ Performance tuning | Every object fetch includes auth + policy evaluation. Help benchmark latency, optimize in-memory caching, and explore async audit strategies. |
| 🏗️ High availability (HA) | A gateway outage shouldn't mean a data outage. Design resilient HA topologies using stateless pods, load balancers, or sidecar approaches. |
| 🛡️ Policy engine evolution | Should we use YAML? Rego? Cedar? Help shape the policy language, embed a battle-tested engine, and unlock tooling support. |
| 🏷️ Metadata & tag enforcement | ABAC requires clean, immutable tags. Build CLI tools or upload hooks to guarantee metadata consistency and prevent drift. |
| 🏢 Multi-tenant isolation | Secure SaaS-style deployments need namespacing, quotas, and noisy-neighbor controls. Architect strong tenant boundaries from the ground up. |
💡 Want to leave your mark on open-source data governance? IronBucket is your forge.
- 📘 Publish a threat model: Diagram trust boundaries (client → gateway → policy engine → store) and highlight mitigations.
- 🧪 Policy dry-run mode: Let teams simulate access before merging changes to
main. - 💻 CLI for dev laptops: A lightweight dev proxy to test policies locally without prod risk.
- 🧩 Pluggable storage adapters: Start with S3/MinIO, but leave room for Wasabi, Backblaze, or future targets.
- 🧱 Roadmapped integrations: Explicitly support Keycloak/Auth0, GitHub/GitLab, and CI/CD hooks so users know what’s stable.
flowchart TD
U[User / Tool] --> GW[IronBucket Gateway]
GW --> PE[Policy Engine]
GW --> GIT[Git Policies]
PE --> S3[S3 Proxy Layer]
S3 --> STORE[S3-Compatible Store]
- User connects to
localhost:7085/s3 - Redirected to Keycloak for authentication (log in as Bob
devor Aliceadmin) - Sentinel-Gear (OAuth2 client) obtains and sanitizes the access token
- Claimspindel (discovered via Buzzle-Vane) introspects the JWT using a custom
ClaimsPredicateFactory - Claimspindel routes the request:
- Users with
roles: dev→brazz-nossel/dev-controller - Users with
roles: admin→brazz-nossel/admin-controller
- Users with
- Brazz-Nossel responds with a personalized greeting:
- “Hallo dev” or “Hallo admin” depending on identity
- ✅ Claims-Driven Routing: JWT claims are parsed and drive routing decisions
- ✅ Dynamic Discovery: Buzzle-Vane (Eureka) enables runtime service discovery
- ✅ Trust Boundaries: Gateways enforce strict trust, no role conflation
- ✅ Route Activation: Controllers respond only when claims match
- ✅ Policy Segmentation: Fine-grained access by role
- ✅ Modular Services: Each service has a clear identity and responsibility
- ✅ Human-Readable Naming: Every component has a memorable, expressive name
- Expand policy matrix for more granular roles
- Harden trust boundaries
- Add automated tests for claim-based routing
- Extend the “living narrative” with richer identities
IronBucket gives your cloud a heartbeat. Identity isn’t just a checkbox—it’s the narrative that connects your services.
- Java 17+
- Docker & Docker Compose
- GitHub/GitLab account
- OIDC provider (Okta, Google, Dex, etc.)
IronBucket policies live in Git as YAML or JSON files. They define who can do what to which resource, under which conditions.
id: read-access-to-project-x
description: Allow devs to read Project X data
subjects:
- group: dev-team
actions: [GET, HEAD]
resources:
- bucket: project-x-data
prefix: /raw/
conditions:
- attribute: region
operator: equals
value: eu-central-1id: qa-read-access
description: Allow QA team to read test data
subjects:
- group: qa
actions: [GET, HEAD]
resources:
- bucket: test-data
prefix: /id: dev-upload-eu
description: Developers can upload only to EU buckets
subjects:
- group: dev
actions: [PUT, POST]
resources:
- bucket: app-logs
prefix: /dev/
conditions:
- attribute: region
operator: equals
value: eu-central-1id: deny-public-access
description: Explicitly deny anonymous access to all resources
subjects:
- user: anonymous
actions: [*]
resources:
- bucket: '*'
prefix: '/'
effect: deny✅ Coming soon:
-
Policy testing & validation CLI
-
Policy dry-run evaluation
ironbucket/
├── gateway-service/ # OIDC auth, token parsing
├── policy-engine/ # Policy evaluation core
├── s3-proxy/ # S3 API proxy layer
├── audit-service/ # Logs, traces, decisions
├── config/ # Shared secrets, certs, constants
├── infra/ # Docker, GitOps templates
└── docs/ # Guides, diagrams, samples
Role: The umbrella project and central policy engine.
Description:
- Defines the architecture, APIs, and integration contracts for building identity- and policy-driven systems.
- Coordinates security, routing, and policy enforcement across the ecosystem.
- Serves as the strategic and technical foundation for all subprojects.
Role: Gateway service for authentication and initial policy enforcement.
Description:
- Acts as the perimeter gateway, providing OpenID Connect (OIDC) authentication and token validation.
- Integrates with IronBucket for policy checks before forwarding requests.
- Entry point for all inbound traffic.
Role: Dynamic JWT gateway and smart routing.
Description:
- Inspects JWTs at the edge and makes real-time routing decisions based on identity claims (region, role, tenant, etc).
- Enforces fine-grained, claim-based access policies before requests reach core services.
- Works with Sentinel-Gear and IronBucket for layered security.
Role: Eureka-based identity-aware service discovery.
Description:
- Registers and discovers services within the ecosystem.
- Guides traffic toward the appropriate service instances based on identity, region, and dynamic policy.
- Ensures context-aware service resolution.
Role: Identity-aware S3 Proxy.
Description:
- Acts as a secure, policy-enforcing proxy for S3-compatible object storage.
- Applies identity-driven access controls to S3 operations (GET, PUT, etc).
- Enables unified policy and identity for both API/service traffic and object storage.
Follow these steps to spin up a minimal working demo of the IronBucket ecosystem:
-
Clone All Repositories
git clone https://github.com/ZiggiZagga/IronBucket.git git clone https://github.com/ZiggiZagga/Sentinel-Gear.git git clone https://github.com/ZiggiZagga/Claimspindel.git git clone https://github.com/ZiggiZagga/Buzzle-Vane.git git clone https://github.com/ZiggiZagga/Brazz-Nossel.git
-
Start Core Identity and Policy Services
- Navigate to the steel-hammer folder inside the IronBucket repository:
cd IronBucket/steel-hammer - Environmentvariables:
Put the path into the double exports below and export the variable
pwdDOCKER_FILES_HOMEDIR.export DOCKER_FILES_HOMEDIR=""
- Launch Keycloak (on port 7081) and Postgres (on port 5432) via Docker Compose:
docker compose -f docker-compose.yml up --build
- Wait for the services to start.
- Verify that Keycloak is running by navigating to http://localhost:7081 in your browser.
- Navigate to the steel-hammer folder inside the IronBucket repository:
-
Start the Java Applications in your IDE (in order):
- before you can run the Java Applications you have to make sure they all have access to the following environment variables:
export IDP_PROVIDER_HOST="localhost:7081" export IDP_PROVIDER_PROTOCOL="http" export IDP_PROVIDER_REALM="dev"
- Start Buzzle-Vane
- Start Sentinel-Gear
- Start Claimspindel
- Start Brazz-Nossel
(You need to do this in your favorite IDE.)
- before you can run the Java Applications you have to make sure they all have access to the following environment variables:
-
Verify the Setup
- Open http://localhost:7085/s3 to access the Sentinel-Gear endpoint.
- You should be redirected to the Keycloak login page.
-
Test Users The system comes preconfigured with two example users:
Username Role Password bob dev bobP@ss alice admin aliceP@ss
🧬 From Project Nessie
Git-style branching & commit semantics
- ✳️ Inspiration: Nessie’s Git-like model for data
- ✅ How we use it: Apply similar mechanics to version access control policies—supporting policy branches (
dev,stage,prod), commit logs, and rollback
Commit metadata & audit
- ⛏️ Inspiration: Nessie tracks user actions across branches
- ✅ IronBucket fit: Record "who edited what" in policy changes for traceability
🛡️ From Apache Polaris
Fine-grained permissions + federation model
- ✳️ Inspiration: Polaris has multi-tenant RBAC and federated query layers
- ✅ IronBucket fit: Adapt its role definition granularity and hierarchical access controls for multi-project S3 namespaces
Attribute-tag-aware enforcement
- ⛏️ Inspiration: Data tags + policy enforcement at query time
- ✅ IronBucket fit: We apply tags to objects and enforce ABAC rules at access time (e.g.,
user.region == object.tag.region)
🧭 From Unity Catalog (conceptual since it’s closed-source)
Centralized governance with identity awareness
- ✳️ Inspiration: Global identity-based permissions across workspaces
- ✅ IronBucket fit: Global RBAC/ABAC rule definitions, synced across services via Git, linked to real identity provider attributes
Lineage-as-a-feature
- While full lineage isn’t core to us, we could log object usage and produce lineage-style metadata for access—for audit or downstream triggers
🚀 From Gravitino
Schema-level metadata & governance layer
- ✳️ Inspiration: Gravitino abstracts metadata across catalogs
- ✅ IronBucket fit: Although we’re staying out of table land, Gravitino’s catalog of governance objects could inspire our policy object model—defining storage buckets, roles, and constraints in a unified structure
If we align all that into our domain, here's what we'd implement:
- Git-backed policy store with Nessie-like branches and commits
- Attribute-driven access control via Polaris-style tags + ABAC
- Unified identity layer inspired by Unity Catalog, aware of OIDC roles, groups, entitlements
- Governance object graph modeled a bit like Gravitino, but constrained to buckets, prefixes, and roles—not tables or schemas
🤝 Contributing We love contributors! Check out CONTRIBUTING.md and browse our open issues.
📝 License
🌐 Community 💬 Discussions
🧵 Slack/Discord – coming soon