Troubleshooting AWS BugBust identity and access - AWS BugBust

Troubleshooting AWS BugBust identity and access

Use the following information to help you diagnose and fix common issues that you might encounter when working with AWS BugBust and IAM.

I am not authorized to perform an action in AWS BugBust

If the AWS Management Console tells you that you're not authorized to perform an action, then you must contact your administrator for assistance. Your administrator is the person that provided you with your username and password.

The following example error occurs when the mateojackson IAM user tries to use the console to view details about a fictional codeguru-reviewer resource but does not have the fictional bugbust:ListBugs permissions.

User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: bugbust:ListBugs on resource: codeguru-reviewer

In this case, Mateo asks his administrator to update his policies to allow him to access the codeguru-reviewer resource using the bugbust:ListBugs action.

I am not authorized to perform iam:PassRole

If you receive an error that you're not authorized to perform the iam:PassRole action, your policies must be updated to allow you to pass a role to AWS BugBust.

Some AWS services allow you to pass an existing role to that service instead of creating a new service role or service-linked role. To do this, you must have permissions to pass the role to the service.

The following example error occurs when an IAM user named marymajor tries to use the console to perform an action in AWS BugBust. However, the action requires the service to have permissions that are granted by a service role. Mary does not have permissions to pass the role to the service.

User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole

In this case, Mary's policies must be updated to allow her to perform the iam:PassRole action.

If you need help, contact your AWS administrator. Your administrator is the person who provided you with your sign-in credentials.

I want to view my access keys

After you create your IAM user access keys, you can view your access key ID at any time. However, you can't view your secret access key again. If you lose your secret key, you must create a new access key pair.

Access keys consist of two parts: an access key ID (for example, AKIAIOSFODNN7EXAMPLE) and a secret access key (for example, wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY). Like a user name and password, you must use both the access key ID and secret access key together to authenticate your requests. Manage your access keys as securely as you do your user name and password.

Important

Do not provide your access keys to a third party, even to help find your canonical user ID. By doing this, you might give someone permanent access to your AWS account.

When you create an access key pair, you are prompted to save the access key ID and secret access key in a secure location. The secret access key is available only at the time you create it. If you lose your secret access key, you must add new access keys to your IAM user. You can have a maximum of two access keys. If you already have two, you must delete one key pair before creating a new one. To view instructions, see Managing access keys in the IAM User Guide.

I'm an administrator and want to allow others to access AWS BugBust

To allow others to access AWS BugBust, you must create an IAM entity (user, role, or group) for the person or application that needs access. They use the credentials for that entity to access AWS. You must then attach an IAM policy to the entity that grants them the correct permissions in AWS BugBust.

AWS BugBust supports two managed policies, AWSBugBustFullAccess and AWSBugBustPlayerAccess. For more information, see AWS managed (predefined) policies for AWS BugBust.

I want to allow people outside of my AWS account to access my AWS BugBust resources

You can create a role that users in other accounts or people outside of your organization can use to access your resources. You can specify who is trusted to assume the role. For services that support resource-based policies or access control lists (ACLs), you can use those policies to grant people access to your resources.

To learn more, consult the following: