I need to get evidence about the role assigned to my user.
Mi role it's supose to be It_Support.. some kind of global viewer role.. when I check in IAM it only shows the roles to proyect level, and i'm not assigned to the project.. my guess is that my role is assigned above this level and I don't know how to get it.
Thanks
I need a shell command or instructions to get the role
Related
I want to create my Cloud Build API but I have not the proper permission. I know how to add permissions and am able to add roles to my IAM however the error message leaves me clueless in what permission I actually need or what role holds that permission.
These are my current roles:
Service Account Key Admin
Organization Administrator
Project IAM Admin
Can someone give me the role or permission name so I can look it up?
Following the official IAM documentation on Cloud Build, I think that the role of roles/cloudbuild.builds.editor could serve you well, since it grants full control of Cloud Build resources. Even though you have set the correct IAM permissions, you need to specify an specific role for this API. Please, tell me if this has helped you.
The Editor role seems to contain the needed permission. However it has a lot of excess permissions so it's not the perfect solution
I've created a custom role in GCP, which I'm using to assign limited access to our business users, enabling them to train the chatbot. At the moment they can perform the functions as needed using the Training module, I would also like to give access to the History module, but I keep hitting an error
IAM permission 'dialogflow.conversations.list' on 'projects' denied.
When I try and add this permission, it's not available. I've noticed the second I make a copy of a standard dialogflow permission group, this object goes missing.
Any suggestions on how I can enable access to this module?
Add Permissions Screenshot
According to Google document, Not all permissions can be used for custom IAM role.
Custom IAM role has a limitation that some permissions are not available.
Below is description about limitation of custom IAM from google document page.
Some predefined roles contain permissions that are not permitted in
custom roles. To check whether you can use a specific permission in a
custom role, see Support level for permissions in custom roles.
Also, I checked whether dialogflow.conversations.list permission is permitted or not. But It didn't even exist.
You can also check it here.
I think you can just grant a dialogflow.conversationManager role to group or users for your situation.
That dialogflow.conversationManager role looks perfect, I'll switch to that.
Many thanks!
I'm planning to develop a multi tenant platform based on the AWS stack. For each customer, let's call them customerA and customerB I want to create individual resources and restrict them that customerA can't see all stuff from customerB.
The first step to set up for the customer is to set up an IAM user with rights to manage all rights for the user. So I want to give the IAM user the rights to create IAM roles and policies and assign them to users but only for the ARN with the resource name customerA__* as prefix. This way it's possible to give the user the rights to create for example roles giving dynamoDB create table rights with a role name of customerA__rolename as planned but I want to further limit it that all roles also need to be bound to this scope, otherwise customerA__deleteTable could also be used to delete customerBs tables.
So in short: Is it possible to create an IAM role that limits all rights to have the name customerA__xyz and also to limit it's scope for each created role to resources with the name customerA__*
If it's not possible any other suggestions how to set up multi tenant rights for AWS? I don't want to create a separate AWS account for each customer for separation and I doubt this can be automated in a legal way.
Thanks in advance :)
There is indeed functionality for this by writing a permission boundary that prevents an IAM user from actually granting more permissions than they already have (which would allow them to bypass this).
A permissions boundary will be evaluated before the permissions so it will take a higher precedence than any permissions a user can set.
AWS have actually created a thorough policy you can use for this use case on their How can I use permissions boundaries to limit the scope of IAM users and roles and prevent privilege escalation? documentation page.
If you add this within your account you should be able to validate that it provides the functionality that you're expecting.
I'm currently working on a task to configure credential rotation in AWS Secret Manager, I did some reading, from my understanding, the best practice is to use the feature on Secret Manager Console 'enable the rotation', then SM will create a Lambda function and perform the rotation on a schedule that we defined (e.g. rotate every 30 days etc), but it seems like it requires IAMFullAccess role to configure this, my question is how can I check if my current AWS account has the full access or does it mean I must use root account to configure this? Many thanks.
No, you don't need root access to configure Secrets Manager key rotation. As a general rule, you should disable root access once you've set up appropriate IAM users. There are very few tasks that actually require root access.
To check your IAM policies, go to the IAM Console and list the policies attached to you (if you are an IAM user and/or in an IAM group) or to the IAM role that you assumed (if you are a federated/SSO user). If you can't access these IAM resources then you don't have full IAM access.
Note that you don't necessarily need to have the managed policy named IAMFullAccess, though that's commonly a way used to give you the relevant IAM permissions. You essentially need the permissions that that managed policy gives you (which is iam:* on all resources).
I am currently learning AWS, and I stumbled upon this scenario where I want to grant access to a service to a user within the same AWS account as mine, using Roles.
So here is the detail of the scenario I am thinking of,
I am currently an admin IAM user 'A'. There is another IAM user 'B' with no access to EC2 service (infact he has access to nothing in AWS!).
I want this user B to temporarily have read-only access to EC2 instances. So I create a role, and attach a policy 'AmazonEC2ReadOnlyAccess' to it.
Now, I want 'B' to switch to this role when he logs in, so that he can view Ec2 instances.
I am aware that this can also be done by creating a group and assigning the policy to that group, and then adding this user 'B' to that group.
But I want to do this using roles.
I am not sure if this is even possible in AWS (or worse if this scenario itself is valid?), because the documentation only speaks about cross-account role switch.
Can anyone help me understand this, and let me know if this is even possible and what I need to do?
I'm not sure why you would do it like this rather than either:
Applying the role to a group and adding the user to a group
Applying the policy directly to a user.
I think you CAN do what you're trying to achieve, but only by giving the user permission to assume a role via a policy, which would mean you would have to give the user permissions via a policy or group anyway (I'm also not sure if this works for roles within the same account) - in this scenario it just makes more sense to apply the policy to the user directly, rather than doing switch roles.
If you really want to go ahead and use switch roles for this, you should be able to modify the guide here to allow you to do so:
https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html
If you wish to add an IAM user you simply attach the user to the roles trusted entity directly, for an IAM user group it is more complicated.
An additional policy is required to add the IAM user group to the role, as it is otherwise not possible to add IAM user groups to roles. As a result you have 2 policies for each permission to give rather than just 1.
UserGroup → Policy#1 → Role → Policy#2
Policy#1 is attached to the UserGroup and has a sts:assumeRole permission for the Role
Role has a trusted entity for the account it is actually in eg. arn:aws:iam::AWS_ACC_ID:root
Policy#2 has your actual permissions, and is attached to the role.