Here's a pattern that shows up on almost every multi-cloud team eventually.
An engineer sets up read-only access to the company's databases — an IAM role in AWS, a service account JSON key in GCP, an API key for MongoDB Atlas. It takes some care to get right: scoped permissions, no write access, nothing that touches other cloud services. That part is usually fine, because one person did it once.
The problem starts right after. A new engineer joins and needs to see what's running in staging. A product manager wants to check a table without filing a ticket. A teammate on a different project needs the connection string for a database they don't normally touch.
Now someone has to decide: do we hand out a copy of the credentials, or does everything keep routing through the one person who has them?
Neither answer is good.
The Credential-Sharing Trap
Copying IAM keys or service account files around a team is a well-known anti-pattern, and most engineers already know why:
- There's no way to revoke access for one person. If a teammate leaves or changes teams, you either rotate the credential for everyone or you leave it live.
- There's no record of who actually used it. A shared key doesn't tell you who ran what — it's one identity for however many people have the file.
-
It spreads. Once a credential lives in a Slack DM or a shared
.envfile, you've already lost track of every place it exists.
So teams default to the other option: route everything through whoever originally set up the connection. That person becomes a bottleneck for anything database-related, which defeats the entire point of giving the team visibility in the first place.
Neither of these is a credentials problem, really. It's an access-model problem — cloud IAM was built to control who can touch AWS or GCP resources, not to control who on your team can look at a schema or run a read-only query.
What Actually Fixes This
The fix isn't a better way to share secrets. It's not needing to share them at all.
When we built 1DataCloud, this is why the credential and the team access are two completely separate layers:
One person connects the account. An engineer adds the AWS IAM role, the GCP service account, or the Atlas API key exactly once, directly to 1DataCloud. The credential lives in one place.
The organization controls who sees what's connected. Access from there is managed at the team level — only people who've been added to your 1DataCloud organization can see or query the databases that organization has connected. Adding a new teammate means adding them to the org, not minting or copying a cloud credential.
Nobody downstream ever touches the credential. A teammate who's been added to the org opens the dashboard, sees the databases already connected, and works with them directly — they never see the IAM role, the service account file, the connection string, or the AWS or GCP console itself.
That's the whole shift: the cloud credential answers "can this platform read this database," once. The organization membership answers "can this person use it," separately, and that's the part that actually changes as your team changes.
What This Looks Like Day to Day
Onboarding a new engineer stops being "here's a shared key, don't lose it" and becomes "you're added to the organization" — they get the same view everyone else has, with nothing to configure and no secret to hand over.
Offboarding is the same operation in reverse: remove them from the organization and their access to every connected database goes with it, without touching the underlying AWS or GCP credential at all.
A non-technical teammate — a PM, an analyst, a support lead — can be added to the organization and use Query1AI to ask questions in plain English against a database's already-mapped schema. They get answers. They never see a connection string, a table name, or a console, because none of that was ever something they needed in the first place.
The engineer who set up the connection stops being the only path to the data. They did the IAM work once; everyone else works through the organization, not through them.
Why This Matters More as You Add Clouds
This gets more important, not less, the more providers you're running. An AWS IAM role, a GCP service account, and an Atlas API key are three different credential formats with three different rotation and permission models. Asking every teammate who needs visibility to understand and safely hold copies of all three doesn't scale past a couple of people.
Separating "who holds the cloud credential" from "who can use the data" means that distinction only has to be solved once, by the person connecting the account — not re-solved for every engineer, PM, or analyst who needs to look at something afterward.
The Short Version
If your current process for giving a teammate database visibility involves sending them a key, a .env file, or a console login, that's the part worth fixing — not by finding a better way to send secrets, but by not needing to send them at all.
Connect the account once. Add people to the organization, not to the credential.
How does your team currently handle this — shared credentials, a secrets manager, something else? Curious how much of this is already solved vs. still painful.
Top comments (0)