Access for Each Platform
You set up access for each platform by mapping central user groups to native roles. Then you require single sign-on before any user can log in. Most teams start by linking their identity provider to cloud consoles and databases. They often assign broad admin roles so engineers can fix bugs fast. Over time, those wide permissions create big security risks across your systems. How to set up access for each platform Every tool in your stack handles users and roles in its own way. A cloud host us
Teleport Access Platform: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up access for each platform by mapping central user groups to native roles. Then you require single sign-on before any user can log in. Most teams start by linking their identity provider to cloud consoles and databases. They often assign broad admin roles so engineers can fix bugs fast. Over time, those wide permissions create big security risks across your systems.
How to set up access for each platform
Every tool in your stack handles users and roles in its own way. A cloud host uses policy files to control who can spin up servers. A database uses internal role grants to control who can read or write tables. Kubernetes checks group claims inside tokens before it runs any cluster command.
To manage this well, you first build groups in your main identity provider. Each group matches a real job function, like backend engineer or data analyst. Next, you create matching roles inside every database, cluster, and cloud account. You give each local role the minimum rights needed for daily work.
Finally, you link your central identity provider to each tool using standard login protocols. When an engineer logs in, the identity provider sends a signed token. The target system reads the group claim and applies the matching local role. This setup keeps user lists in one place while keeping local rules intact.
What native platform roles solve and what they miss
Linking central groups to native roles solves the basic problem of user sprawl. When someone leaves the team, you disable one account in your identity provider. That person can no longer log in to any linked system. You also avoid sharing static passwords or long-lived keys in chat channels.
Still, native setup only checks who can log in at the start. Once a session begins, the system trusts every command that fits the role. A role that allows table reads will return every column in that table by default. The database will send back raw emails, phone numbers, and card numbers.
Broad roles also fail to stop dangerous commands during a live session. An engineer with write rights to fix one row can drop a whole table. Native logs across different tools also use different formats and detail levels. Pulling together a clear audit trail across five systems takes hours of manual work.
Teleport Access Platform: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Why teams struggle with role sprawl over time
As a company grows, teams add new databases, queues, and internal apps. Each new tool brings its own permission model and role syntax. Admins must learn how each system defines read, write, and admin rights. Small mistakes in role setup can grant much wider rights than planned.
Engineers also ask for temporary rights to fix urgent production issues. Admins grant those rights inside the local tool to save time. Very often, nobody remembers to remove those extra permissions after the fix. Months later, basic user roles hold deep admin rights across multiple systems.
Auditors then ask for proof of who ran what command on production data. Teams must export logs from every single database and cloud console by hand. Even then, many native logs only show when a user logged in. They do not show the exact queries run or the sensitive fields returned.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
Why not use one single admin role for every engineer?
Shared admin roles make it impossible to see who ran a bad command. They also expose sensitive data like national IDs to everyone on the team.
How often should teams review native platform permissions?
Teams should check role grants at least once every quarter. Removing unused rights early stops old accounts from holding dangerous production permissions.
Do identity providers control what queries a user can run?
No, an identity provider only checks who you are during login. The local database or server decides which commands and queries can run.