The simplest way to make Cloud Run MinIO work like it should

You finally got Cloud Run deployed. It scales perfectly, logs look fine, then your app tries to hit MinIO and everything halts. Credentials vanish between revisions, signed URLs expire too fast, and storage policies drift across environments. The pairing should be simple, but the real trick is keeping access both stateless and secure.

Cloud Run and MinIO sit on opposite ends of your cloud workflow. Cloud Run runs code without servers, scaling to zero when idle. MinIO acts as your high-performance object store, S3-compatible and happy to host build artifacts, data sets, or raw media. When integrated correctly, Cloud Run MinIO turns into a low-friction data layer for any containerized workload.

The integration workflow starts with identity. Cloud Run services use a service account, which MinIO can trust via OpenID Connect. That trust is your golden key. Instead of baking API keys or IAM credentials into your container, let Cloud Run’s identity token authenticate directly with MinIO. The token can be validated by MinIO’s OIDC config, giving you short-lived, verifiable access every time a function runs.

Permissions come next. Map Cloud Run’s service account to a MinIO policy that limits what objects or buckets it can touch. Read-only for analytics, write scopes for ingest services, and full control only in controlled build pipelines. Versioning these policies as code keeps them transparent and auditable. Add rotation rules or short token TTLs if you care about SOC 2 or ISO-style compliance.

If you see signature errors, check timestamps. Cloud Run instances spin up fast, but time drift can hit authentication TTLs. Another common trap is bucket naming across regions; align those with your Cloud Run service URLs to avoid awkward cross-latency calls.

Why this pairing matters:

• You get stateless, identity-driven storage with zero static keys.
• RBAC and policy mapping remain in version control, not tribal memory.
• Audit and compliance checks become easier to prove.
• Cold start overhead drops because credentials are created on demand.
• Scalability feels natural—each container trusts MinIO automatically.

For developers, this means fewer IAM tickets and faster iteration. No one pauses to request new access secrets. Your CI pipeline builds, deploys, and validates storage access in one motion. The security model scales as fast as your code does.

Platforms like hoop.dev turn those access rules into guardrails that enforce policy automatically. It reads identities from your provider (Okta, Google, or AWS IAM) and ensures that only the right workloads hit MinIO through Cloud Run endpoints. You get policy as guardrail, not red tape.

How do I connect Cloud Run to MinIO quickly? Set up MinIO with an OIDC provider, point it to your Cloud Run service account issuer URL, then assign policies tied to each service identity. No static keys needed, no long-term tokens left behind.

As AI assistants start managing infrastructure, this pattern becomes even more critical. If a copilot script tries to fetch test data, identity-aware storage ensures it sees only what it is allowed to. Automation stays powerful without turning reckless.

The real win is simplicity: Cloud Run MinIO works like it should when identity becomes the network handshake itself.

See an Environment Agnostic Identity-Aware Proxy in action with hoop.dev. Deploy it, connect your identity provider, and watch it protect your endpoints everywhere—live in minutes.