How Elestio accesses your T Cloud account
A dedicated IAM user, six explicitly scoped policies, and a KMS permission that is read only because Elestio never creates encryption keys. Every action is attributable in your own audit trail, and you revoke access from your own console without asking us.
Principles
Three commitments that shape the whole access model
This page exists to be forwarded to your security team. It describes exactly what Elestio can reach inside your T Cloud account, what it cannot, and how you take that access away.
Elestio never holds your encryption keys
The KMS policy we request is read only. Elestio reads the evs/default key that already exists in your account to encrypt root volumes at creation. We cannot create, rotate, disable or delete any key. The key material stays under your control, in your tenancy, under your jurisdiction.
A dedicated identity, never your root account
Access lives in an IAM user created specifically for Elestio, with programmatic access only and no console password. It is isolated from your existing users and resources, and every API call it makes is attributable to it in your own T Cloud audit trail.
Revocation is yours alone
You disable the IAM user or delete its access key from your own console. It takes effect immediately and you do not need to open a ticket, give notice or ask Elestio for anything. The infrastructure keeps running, it simply stops being managed.
Scope
What each policy grants, and what it does not
Six policies, scoped to all resources across existing and future projects. Here is the honest breakdown of each one.
Practice
What we recommend you do on your side
Elestio asks for a dedicated user because it is better for you, not because it is easier for us.
A five minute hardening checklist
- Create the IAM user with programmatic access only, no console password, named so it is obvious what it is, for example
elestio-service. - Put it in its own user group rather than an existing one, so the policy scope never widens by accident when someone edits a shared group.
- Store the Secret Key immediately. T Cloud shows it exactly once at creation.
- Confirm the
evs/defaultkey exists under Key Management Service before the first deployment. If it is missing, create it yourself, with that exact alias, so the key is provably yours. - Review the user activity in your T Cloud audit trail after the first week. Everything Elestio does is attributable to that single identity.
On the first encrypted disk in an account, T Cloud requires a one-time EVS service agency to be created per region. This is a T Cloud requirement, not an Elestio one, and it is a single confirmation in your console.
Reviews
Trusted by 10,000+ Developers Worldwide
Real reviews from real users on Trustpilot.
"I'm in the IT industry for over 25 years and Elestio stands out in many ways. The managed services are top-notch, support is incredibly fast, and the platform just works. Couldn't be better!"
FAQ
Frequently Asked Questions
-
Does Elestio have access to our encryption keys?
No. The KMS policy Elestio requests is CMKReadOnlyAccess, which is read only. Elestio reads the evs/default key that already exists in your account in order to encrypt root volumes at creation time. Elestio cannot create, rotate, disable or delete any key, and the key material never leaves your tenancy.
-
Can Elestio see our billing or our other IAM users?
No. None of the six policies grant access to billing, payment methods, your other IAM users or your identity configuration. The scope covers compute, block storage, networking, read-only key access and DNS records.
-
Why does the scope have to cover future projects?
Because Elestio provisions new resources on your behalf. If the scope were limited to projects that existed at setup time, every new deployment would fail until someone manually widened the permission. Restricting it to existing projects only is possible, but it means a manual step before each new service.
-
How do we revoke access?
Disable the IAM user or delete its access key in your own T Cloud console. It takes effect immediately, requires no notice period and no ticket with Elestio. Your servers keep running, they simply stop being managed.
-
Can we audit what Elestio did?
Yes. Because Elestio operates through a single dedicated IAM user, every API call it makes is attributable to that identity in your own T Cloud audit trail. You do not depend on Elestio for the log, it is in your account.
-
Do you need our root credentials at any point?
No, and we recommend against it. Elestio explicitly asks you to create a dedicated IAM user with programmatic access instead of using root account credentials, so your existing resources stay isolated and access stays attributable.
Send this page to your security team
A scoped identity, read-only key access and revocation you control. Then the operations layer on top.
Get Started