Sts Caller Identity
You check sts caller identity by sending a request to the AWS Security Token Service. This call returns the account ID, user ID, and resource name for your active keys. Teams run this check in local terminals and build scripts before making cloud changes. If a script uses broad permissions in the wrong account, one bad command can delete production data. How sts caller identity works in your cloud workflow Every request to AWS uses a secret key or a temporary token. Developers often juggle ma
Identity and Access Management (IAM): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You check sts caller identity by sending a request to the AWS Security Token Service. This call returns the account ID, user ID, and resource name for your active keys. Teams run this check in local terminals and build scripts before making cloud changes. If a script uses broad permissions in the wrong account, one bad command can delete production data.
How sts caller identity works in your cloud workflow
Every request to AWS uses a secret key or a temporary token. Developers often juggle many profiles on one laptop at the same time. It is easy to lose track of which profile is active in a terminal window. The sts caller identity request solves this problem by asking AWS who owns the current session.
When you send the request, your local tool signs the message with your active secret key. AWS reads the signature and looks up the matching user or role in its database. The service then sends back three simple pieces of text. You see the twelve-digit account number, the unique caller ID, and the full resource path.
The best part about this check is that it always works for valid keys. You cannot block this specific call with standard permission policies. Even if a role has zero permissions to read or write resources, this identity check still succeeds. Security teams use this behavior to test if a key is active without granting extra rights.
What native identity checks solve and what they miss
Running an identity check before a deploy stops many simple mistakes. A build script can read the returned account number and compare it to an expected value. If the numbers do not match, the script stops right away. This simple check prevents a developer from running test scripts against a live production account.
Still, checking who is logged in only solves half of the safety problem. Cloud roles are often too broad because teams share them across many tasks. Once a user or script passes the login check, AWS allows every action permitted by that role. The identity service does not inspect the actual database queries or shell commands that run next.
Shared roles also make audit logs hard to read during an incident. Five engineers might assume the same admin role to fix a broken server. The cloud log shows the shared role name, but it hides which engineer ran a specific command. Also, the cloud identity service cannot mask sensitive fields like emails or card numbers in query results.
Identity and Access Management (IAM): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Best practices for managing temporary role sessions
Start by removing long-lived static keys from developer laptops whenever you can. Static keys sit in plain text files on disk and never expire on their own. Instead, have your team log in through a central single sign-on provider. This flow hands out short-lived tokens that expire after a few hours.
Next, split large admin roles into smaller roles built for single tasks. Give a read-only role for daily debugging and a separate role for schema updates. When engineers check their active identity, the role name itself will remind them of their current power.
Finally, add an automatic identity check to the start of every local automation script. Print the account number and role name to the screen before the script changes any state. Giving the engineer a five-second pause to read the output catches account mix-ups early.
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
Does checking sts caller identity cost money or count against limits?
AWS does not charge a fee for requests to the Security Token Service. Still, the service does enforce a regional rate limit if thousands of scripts call it at once.
Can an admin block a user from running an identity check?
No, you cannot block this call with identity policies or service control policies. If the access key and secret key are valid and active, the call always returns the caller details.
How does this check help detect leaked access keys?
Defenders can set up alerts in cloud audit logs to watch for this specific call. Attackers almost always run an identity check first to see what a stolen key can do.