k9 Security now summarizes principals’ access to the STS APIs and reports whether principals may use resources, read data, or write data via the STS API. AWS Security Token Service (STS) is a service that enables you to request temporary, limited-privilege credentials to use an IAM role. k9 Security’s daily reports now contain a summary of each principal’s access to the STS APIs.

If you’re wondering which IAM principals can assume roles within an AWS account or into another account, k9 can give you a short list to review. IAM principals allowed to call one of the three sts:AssumeRole* API actions will have the use-resource k9 access capability.

Here’s an example of how STS access is summarized in the Principal Access Summary worksheet of k9-dev’s report (sample: xlsx):

Figure 1: Example showing STS APIs access for IAM Principals

In this example the ci IAM user and the AccountAdminAccessRole-Sandbox have read-data, write-data, and use-resource capabilities to the STS API. The k9-backend-dev has only the use-resource capability.

Here’s how STS service actions are mapped to k9 access capabilities:

Table 1: Mapping of STS API actions to k9 Access Capabilities

The STS API actions allowing one IAM principal to use another IAM principal are classified as use-resource. If a principal may use other IAM principals, then two other capabilities are relevant.

The read-data capability indicates an IAM principal has the ability to read information about the STS session or the account that granted it. For example, sts:GetCallerIdentity returns the assumed role’s AWS account ID, ARN, and unique user ID. This information is very useful for debugging, security monitoring, and surveillance.

The write-data capability contains API actions that enable an IAM principal to change the session or reveal debugging information from errors that occurred within the session.

We hope k9’s new STS analysis capabilities help you identify which users and roles can access other identities and are happy to answer any questions!