You sign up for a new tool to see your infrastructure in one place. First onboarding step: "Connect your cloud". And the form asks for the tenancy's admin API key. The master one. The one that can create, delete and bill everything. You paste the key because you want to try the tool, and in that same gesture you handed a third party the keys to the kingdom. Stop right there.
The request you should refuse
A global admin credential is "god mode": it can read everything, but it can also drop a production database, open a port to the world, or spin up 200 instances that land on your invoice. When you hand it to a SaaS, that key now lives in another company's database, travels through their logs, is visible to their employees, and is inherited by whoever compromises that system. The blast radius of that single key is your entire account.
And it is almost never necessary. A tool that "visualises your infrastructure" needs to READ resources. It does not need to be able to destroy them. Asking for the master key is, almost always, engineering laziness on the product side: it is easier to ask for everything than to ask for exactly what you need.
What BYO credentials means
BYO ("bring your own") flips the model: instead of the tool telling you "give me a key that works for everything", you create a credential specific to that tool, with the minimum permission it needs, and hand that over. The key is yours, you created it, and you can switch it off at any moment without asking anyone.
- Least privilege: only the permissions the tool actually uses. If it only reads, it should only be able to read.
- Narrow scope: limited to one compartment / resource group / project, not the whole account.
- Its own identity: one credential per integration, not a human's personal key shared by everyone.
- Revocable: you delete it and the integration stops working, without taking anything else down.
Read by default, write explicitly
The healthy rule is that a tool starts read-only. Mapping, inventory, showing costs, drawing the dependency graph: all of that runs on read permissions. The day you want the tool to also apply a change, that is a separate, explicit decision, with its own write credential scoped to the specific resource. Not a permission that came free in the onboarding bundle.
Revocable without breaking anything else
This is the acid test of the BYO model: if you stop trusting the tool tomorrow, what does it cost you to cut it off? With a shared master key, revoking it breaks everything else that was using it and forces you into a chain of credential rotations. With a dedicated least-privilege credential, you delete it in 30 seconds and the rest of your account never notices.
The question is not "do I trust this tool?". It is "what happens the day I stop trusting it?". If the answer is "I have to rotate my whole account's key", the model was already wrong.
How Control Cloud does it
Control Cloud is BYO by default: you create a read-only credential in your cloud, scoped however you like, and load it in. We never ask for the tenancy admin key, and we never need it for what the product does: see your infrastructure, draw dependencies and warn you before a destructive change. You hold the key, you switch it off.
If some tool is asking for more permission than its function justifies, that is all the signal you need. Connect a cloud read-only and see how much can be done without handing over the keys to the kingdom.
Top comments (0)