In my AWS console (IAM -> Access Management -> Roles), I noticed a service-linked role among the list of all the roles.
How do I determine what AWS resources can assume this service-linked role. I'm asking because I'm auditing a system and trying to get a handle on what permissions may be in use elsewhere. Someone (don't know who) created it for a reason. I'd like to figure out why.
How can I tell what is using this service-linked role?
Service Linked roles are by-design used by one particular AWS service.
In the AWS Management Console for the IAM service, you can click on a role and view the "Summary". The summary contains a path attribute which looks like the following: /aws-service-role/access-analyzer.amazonaws.com/.
In this example you can see that the service which uses this role is called Access Analyzer.
You can get information on the Service-Linked role for that particular service in the docs. [1]
Navigate to section "Security, Identity, and Compliance Services" -> search for row "IAM Access Analyzer" and click on the link Yes in the "Service-linked roles" column of the table. The linked docs usually tell you why AWS sets up this particulal service linked role and which permissions it includes.
General information about service linked roles is given by the IAM docs on "Service-Linked Roles" [2] and the IAM "Troubleshooting" guide [3].
If you want to know when a particular service linked role was last used in your account, use the Access Analyzer [4].
There are currently 3 posts on the topic service linked roles from the AWS official blog [5]. Two of them are probably related to your question:
The blog post "Greater Transparency into Actions AWS Services Perform on Your Behalf by Using AWS CloudTrail
" [6] goes into detail how to monitor the actions which are performed by the role. This is the procedure also suggested by #jellycsc's answer I guess.
Excerpt from the blog post [6]:
In this blog post, I demonstrate how to view CloudTrail logs so that you can more easily monitor and audit AWS services performing actions on your behalf. First, I show how AWS creates a service-linked role in your account automatically when you configure an AWS service that supports service-linked roles. Next, I show how you can view the policies of a service-linked role that grants an AWS service permission to perform actions on your behalf. Finally, I use the configured AWS service to perform an action and show you how the action appears in your CloudTrail logs.
The blog post "Now Use AWS IAM to Delete a Service-Linked Role When You No Longer Require an AWS Service to Perform Actions on Your Behalf" [7] makes the following statement:
When you delete a service-linked role, the linked service no longer has the permissions to perform actions on your behalf. To ensure your AWS services continue to function as expected when you delete a service-linked role, IAM validates that you no longer have resources that require the service-linked role to function properly. This prevents you from inadvertently revoking permissions required by an AWS service to manage your existing AWS resources and helps you maintain your resources in a consistent state. If there are any resources in your account that require the service-linked role, you will receive an error when you attempt to delete the service-linked role, and the service-linked role will remain in your account. If you do not have any resources that require the service-linked role, you can delete the service-linked role and IAM will remove the service-linked role from your account.
References
[1] https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html#admin_svcs
[2] https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#create-service-linked-role
[3] https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared
[4] https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html?icmpid=docs_iam_console
[5] https://aws.amazon.com/de/blogs/security/tag/service-linked-roles/
[6] https://aws.amazon.com/de/blogs/security/get-greater-transparency-into-actions-aws-services-perform-on-your-behalf-by-using-aws-cloudtrail/
[7] https://aws.amazon.com/de/blogs/security/now-use-aws-iam-to-delete-a-service-linked-role-when-you-no-longer-require-an-aws-service-to-perform-actions-on-your-behalf/
Use CloudTrail. Here is the doc. You might want to explore more of it.
Related
The PubSub service account is service-<PROJECT_NUMBER>#gcp-sa-pubsub.iam.gserviceaccount.com
The command described here to create an IAM policy binding succeeds, which shows that the service account exists.
But it does not appear in
the list of service accounts in the console https://console.cloud.google.com/iam-admin/serviceaccounts?project=<PROJECT> (screenshot below)
nor in the IAM permissions list https://console.cloud.google.com/iam-admin/iam?project=<PROJECT> , even when I check "Include Google-provided role grants"
nor in the output of gcloud iam service-accounts list --project <PROJECT>.
Where can I see this service account listed?
The service-<PROJECT_NUMBER>#gcp-sa-pubsub.iam.gserviceaccount.com is a Google managed service account, therefore, you can see it in the list YOUR PROJECT service accounts.
In addition, you have granted this service account on a TOPIC resource and not on a PROJECT resource. Therefore, when you go on the iam-admin page, you can see the service account at the PROJECT ressource.
Anyway, you could be able to view it in the iam-admin page by checking Include Google-provided role grants
Because you have granted the service account at TOPIC resource level, you can see it in the TOPIC page
Go to the topic page, check a topic and go to the right-hand panel, in the permission section and look at the role that you grant on the service account. You will find it
I have a problem when creating a Role I am getting an error that says “Cannot attach a Service Role Policy to a Customer Role”
In fact, there is something called Customer Managed Role, which the above error seems to display as 'Customer Role'.
From AWS documentation (https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-role)
A role that a service assumes to perform actions in your account on your behalf. When you set up some AWS service environments, you must define a role for the service to assume. This service role must include all the permissions required for the service to access the AWS resources that it needs.
Now if you create a role, which isn't a service role, and attach permissions yourself, it appears under what AWS shows as Customer Managed Role (Screenshot below). If you look carefully, the service roles in AWS show the AWS box icon and the Customer Managed ones don't.
Reason: I was facing the above error as well and the reason was that my Role had custom inlined policies attached. If a Role has custom attached policies (inlined), AWS doesn't let you attach the Service Roles to it. You can filter the roles and find out what's causing the issue.
I hope this is documented somewhere as I was scratching my head for quite some time on this.
I just created a new account in my organization and I provided a custom IAM role.
The problem is that I can't find the role in IAM, I remember then name and in any case there are few roles there so I can check.
I double checked in cloud trail the IAM role name, and I search for it in IAM and I still can't find it.
Is there something I'm missing or some workaround?
Background:
According to the documentation:
How can I access an AWS account that was created in my organization?
As part of AWS account creation, AWS Organizations creates an IAM role
with full administrative permissions in the new account. IAM users and
IAM roles with appropriate permissions in the master account can
assume this IAM role to gain access to the newly created account.
Update:
The steps of the link below also helped me understand the issue
https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html
As per the documentation, the role is created in the New account. You can assumeRole by sts service to the role from the master account, so this is the reason you cannot find the role in your account.
You first assumeRole and then you can do the administrative job for the new account. You can log in through this link with your role and account.
https://signin.aws.amazon.com/switchrole?roleName=<roleName>&account=<newAccountId>
Be aware that you should be logged in to your master account first. Replace <roleName> and 12-digits <newAccountId> for yours.
What difference between policies under the paths "aws:policy/service-role" and "aws:policy/aws-service-role"?
Is there any the logic behind this design?
The AWS managed policies within the aws-service-role path are policies that be attached to a service-linked role only.
If you go to AWS Console -> IAM -> Policies, filter by AWS Managed Polices and start clicking on them, you'll notice the ones with the aws-servive-role path have a help label at the top that reads "This policy is linked to a service and used only with a service-linked role for that service. You cannot attach, detach, modify, or delete this policy.". There might be a way to filter down to the service-linked policies in the AWS Console or CLI when desribing policies other than inspecting the paths, but it alludes me right now.
You can see their usage described here
https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html.
Here also is the blog post that describes what a service-linked role is https://aws.amazon.com/blogs/security/introducing-an-easier-way-to-delegate-permissions-to-aws-services-service-linked-roles/. Basically these are roles that can only be assumed by a specific service type.
The AWS managed policies in the service-role path are policies that can be attached to any role including "normal/basic" roles. These types of roles can be assumed by users, EC2 instances, or anywhere else roles are assumed.
For example you could give someone permission to attach a linked-service role that has the policy arn:aws:iam::aws:policy/aws-service-role/AWSLambdaReplicator attached which is only attachable to a linked-role linked to the Lambda service. They would be able to use this role in the Lambda execution role, but they would not be able to use this role with another service like EC2 or an IAM user. This supports an admin allowing users to assign out permissions to new resources that users spins up (a new Lambda) that that the admin trusts the linked AWS service to use, but don't want to allow that user to access directly through their user account or give them to other custom applications running in AWS.
According to the offical AWS documentation, IAM Roles can also be attached to IAM Users, and not only services.
What would be a valid use case to assign an IAM Role to an IAM User?
Aren't all the cases covered by directly granting (allow/deny) IAM Policies to the users?
TBH my initial impression was thar IAM Roles served the purpose of authorization for the AWS services (so that they can interact with other services), since the latter cannot be addressed in the User context
As you clearly understood, AWS Roles serves the purpose of authentication (with IAM policies for authorization) for AWS services. In contrast, AWS IAM users directly maps towards human user who obtains credentials to login to the AWS Management Console.
However, when granting access to an User outside the AWS Account (e.g; Cross Account Access, AD Authentication Federation) it will require an IAM Role to Assume the permission.
Referring to the documentation you shared, its not a direct IAM User who is getting permission, rather an Active Directory user (External) assuming an IAM Role (Not direct IAM User) to get access to the AWS Resources.
It is an IAM best practice is to assign Roles to AWS users from other AWS accounts in order to delegate permissions. This is to avoid sharing credentials between AWS accounts.
I also wanted to point out, your initial impression about Roles as authorization is not correct. The only IAM resource that is considered authorization are IAM Policies.
This can be seen in the AWS documentation on Understanding IAM and in the following AWS training video: Authentication and Authorization with AWS Identity and Access Management (login required)
The other three basic IAM resources: Users, Groups and Roles are considered part of Authentication.