Granted Cli
You use the granted cli to switch between cloud roles from your terminal. It pairs with your single sign-on portal to fetch temporary cloud keys. Platform teams set up this tool so developers can manage many cloud accounts. Developers pick a role from a list and start a local session. Still, broad cloud roles often give users far more power than they need. Once a user assumes a role, they can run risky commands without checks. How the granted cli manages local cloud sessions The tool works on
CLI Authentication Patterns: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You use the granted cli to switch between cloud roles from your terminal. It pairs with your single sign-on portal to fetch temporary cloud keys. Platform teams set up this tool so developers can manage many cloud accounts. Developers pick a role from a list and start a local session. Still, broad cloud roles often give users far more power than they need. Once a user assumes a role, they can run risky commands without checks.
How the granted cli manages local cloud sessions
The tool works on top of your standard cloud command line setup. It reads the account profiles stored on your local machine. When a user picks a profile, the tool opens a browser window. The user logs in through the company identity provider and completes multi-factor checks.
After login, the cloud provider sends back a temporary session token. The tool stores this token in a secure local keystore or shell session. It can also open isolated browser tabs for different cloud accounts at once. This stops browser cookie mix-ups when an engineer checks two accounts at the same time.
Engineers do not have to copy and paste static keys into text files. The tool refreshes expired tokens when the user runs a new command. This workflow makes daily role switching fast for developers and support staff.
Where local role switching leaves security gaps
Local role tools solve the problem of static keys sitting on laptops. They make sure every user logs in through the central identity provider first. They also cut down the time engineers spend switching between cloud accounts. This improves daily speed for teams with dozens of separate cloud projects.
Yet role switching only controls who logs in at the start. It does not inspect what commands or queries the user runs next. Once the session token lands on the laptop, the user has full role power. If a role allows database reads, the user can pull whole tables.
Cloud audit logs show that a role assumed a session at a certain time. They often miss the exact database queries or shell commands run inside private networks. Shared roles also make it hard to tie a bad command to one person. Teams still face the risk of broad permissions and exposed private data.
CLI Authentication Patterns: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Why teams need controls beyond role assumption
Cloud roles are coarse tools for managing daily work across large teams. If you make a new role for every small task, role counts explode. Teams end up maintaining hundreds of tiny policies across many cloud accounts. To avoid this mess, admins fall back to broad read or write roles.
A developer might only need to check one customer row to fix a bug. With a standard role, their local token lets them read every row instead by default. Results can return raw emails, phone numbers, card numbers, and national IDs. Nothing in the local token setup rewrites those fields before they hit the screen.
Real safety requires checking each command and query while it runs. Teams need a way to approve single actions instead of whole four-hour sessions. They also need field masking that rewrites matched fields in query results. Pairing strong login flows with command-level checks closes the gap left by broad roles.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Does the granted cli replace cloud identity providers?
No, it works alongside your existing single sign-on and cloud identity setup. It simply automates the browser login flow and stores the resulting short-lived tokens on your machine.
Can local role tools hide sensitive database fields?
No, a role tool only fetches cloud credentials for your terminal or browser. Once you have the token, the database returns whatever raw data that role is allowed to read.
What happens if a developer laptop has an active cloud token?
Any local process or script running under that user account can use the active token. The token stays valid until its timer runs out or an admin revokes the session in the cloud console.