I'm currently managing a AWS SSO solution using it with AzureAD. For our use case we need to be able to revoke access/session of a user.
In AzureAD it's pretty simple, go to the user, block him, revoke its session. It's done, user needs to relog but he won't be able to do so.
In AWS SSO, it looks a bit harder, I can't seem to find a way to instantly revoke a session. I can disable its access, but once he has a session, even deleting the user/group from AWS SSO will not terminate the session.
This causes quite a problem as this is compliant to my security standards.
Any ideas?
Thanks people
An option is to put in place a temporary SCP on the AWS account to deny all actions for the Role session of the user as shown below:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "UserRestrictions",
"Effect": "Deny",
"Action": "*",
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"aws:userId": [
"AROAEXAMPLEROLEID:alice#example.com"
]
}
}
}
]}
After a day or so (or the max role duration) you could remove the SCP. This is useful if you only have a single role session but in the scenario of an AWS SSO user, the user probably has access to multiple Roles across multiple AWS accounts. Rather than adding multiple SCPs you could add a SCP higher up in the organizational hierarchy that denies actions for all Role sessions for the user as shown below:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "UserRestrictions",
"Effect": "Deny",
"Action": "*",
"Resource": [
"*"
],
"Condition": {
"StringLike": {
"aws:userId": [
"*:alice#example.com"
]
}
}
}
]}
Related
In the CI/CD section of the AWS SAM tutorial workshop, when I ran
sam pipeline init --bootstrap and went through the configurations, a role was created with this policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Action": "*",
"Resource": "*",
"Effect": "Allow"
}
]
}
Doesn't this grant the role complete permission over my AWS account which is a big no no? Or is it fine because the permission is granted to an AWS service, and not a user?
This is the trust relationship:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "cloudformation.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
Having a role that exists with those permissionsis fine.
When you create a vanilla AWS Account (in other words I am not including those created by enterprise landing zones like Control Tower) it comes with a policy called AdministratorAccess and a role called Administrator.
The best practice is in who or what you allow to use that policy and when.
Roles are preferred over users, since roles provide security credentials. With a user you have durable credentials you need to secure.
In this case you are allowing CloudFormation to assume this role. This makes sense since CloudFormation often needs to be able to create and modify any resources including IAM roles. If you know you will not be creating or modifying IAM resources you can user a more restrictive role (least privilege), for example using the PowerUserAccess policy which looks like this:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"NotAction": [
"iam:*",
"organizations:*",
"account:*"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole",
"iam:DeleteServiceLinkedRole",
"iam:ListRoles",
"organizations:DescribeOrganization",
"account:ListRegions"
],
"Resource": "*"
}
]
}
I am trying to create an SCP policy to disallow creation of iam user in member accounts other than Admin (assumed role with SSO), however its not letting even the admin create the user, below is the policy I am using,
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Statement1",
"Effect": "Deny",
"Action": [
"iam:CreateUser",
"iam:CreateAccessKey",
"iam:DeleteAccessKey",
"iam:DeleteUser"
],
"Resource": [
"*"
],
"Condition": {
"StringNotLike": {
"aws:PrincipalArn": [
"arn:aws:sts::*:assumed-role/AWSReservedSSO_AWSAdministratorAccess*/*"
]
}
}
}
]
}
Not sure what's wrong in it, please help
The PrincipalArn should be:
arn:aws:iam::*:role/aws-reserved/sso.amazonaws.com/AWSReservedSSO_AWSAdministratorAccess*
To get an valid ARN for SSO assumed roles, you need to change arn:aws:sts::*:assumed-role by arn:aws:iam::*:role.
Additionally, this represents the SSO group, so you do not need to add /* after the group name. So the following ARN is incorrect and will not work:
arn:aws:iam::*:role/aws-reserved/sso.amazonaws.com/AWSReservedSSO_AWSAdministratorAccess*
Reference:
Implement service control policy (SCP) for accounts in AWS Organizations
I am trying to give admin rights to a specific user group and enforcing MFA for the same group. MFA should be only enforced for console users though, not when using the AWS CLI.
These are the policies I have been testing with:
Policy 1 - Administrator access granted if MFA
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowAdminAccessIfSignedInWithMFA",
"Effect": "Allow",
"Action": "*",
"Resource": "*",
"Condition": {
"BoolIfExists": {
"aws:MultiFactorAuthPresent": "true"
}
}
}
]
}
Policy 2 - Still, allow the user to set up MFA in case it is not yet active
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowViewAccountInfo",
"Effect": "Allow",
"Action": "iam:ListVirtualMFADevices",
"Resource": "*"
},
{
"Sid": "AllowManageOwnVirtualMFADevice",
"Effect": "Allow",
"Action": [
"iam:CreateVirtualMFADevice",
"iam:DeleteVirtualMFADevice"
],
"Resource": "arn:aws:iam::*:mfa/${aws:username}"
},
{
"Sid": "AllowManageOwnUserMFA",
"Effect": "Allow",
"Action": [
"iam:DeactivateMFADevice",
"iam:EnableMFADevice",
"iam:GetUser",
"iam:ListMFADevices",
"iam:ResyncMFADevice"
],
"Resource": "arn:aws:iam::*:user/${aws:username}"
}
]
}
This last policy was adapted from this one.
The official documentation for aws:MultiFactorAuthPresent says, as I understand it, that the combination of "Allow", "BoolIfExists" and "true" should work well for my purpose:
This condition matches either if the key exists and is present or if the key does not exist. This combination of Allow, BoolIfExists, and true allows requests that are authenticated using MFA, or requests that cannot be authenticated using MFA. This means that AWS CLI, AWS API, and AWS SDK operations are allowed when the requester uses their long-term access keys. This combination does not allow requests from temporary credentials that could, but do not include MFA.
If you are wondering why I'm not using any (seemingly simpler) policy containing a "Deny" effect, like:
"Effect" : "Deny",
"Condition" : { "BoolIfExists" : { "aws:MultiFactorAuthPresent" : "false" } }
...the reason is:
This combination of Deny, BoolIfExists, and false denies requests that are not authenticated using MFA. Specifically, it denies requests from temporary credentials that do not include MFA. It also denies requests that are made using long-term credentials, such as AWS CLI or AWS API operations made using access keys. The *IfExists operator checks for the presence of the aws:MultiFactorAuthPresent key and whether or not it could be present, as indicated by its existence. Use this when you want to deny any request that is not authenticated using MFA. This is more secure, but can break any code or scripts that use access keys to access the AWS CLI or AWS API.
Everything works as expected, except for when I try to access resources using the AWS CLI (with an access key).
Am I missing something or is the documentation misleading?
PS: I would like to avoid having separate user groups for console and CLI users.
I'm trying to give a user the rights to create Roles (since I'm not providing rights to create Access Keys).
I have figured out a Policy to allow the user to create and assign Roles.
The issue I have is that right now, the user can create a role with the Policy of "AdministratorAccess" even though they are not Administrator. Is there a way to deny certain policies in the list of options?
Below is the policy done via the wizard provided.
Thanks,
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"iam:CreateInstanceProfile",
"iam:UpdateAssumeRolePolicy",
"iam:ListRoleTags",
"iam:UntagRole",
"iam:PutRolePermissionsBoundary",
"iam:TagRole",
"iam:RemoveRoleFromInstanceProfile",
"iam:CreateRole",
"iam:AttachRolePolicy",
"iam:PutRolePolicy",
"iam:ListInstanceProfilesForRole",
"iam:PassRole",
"iam:DetachRolePolicy",
"iam:DeleteRolePolicy",
"iam:ListAttachedRolePolicies",
"iam:ListRolePolicies",
"iam:ListPolicies",
"iam:GetRole",
"iam:ListRoles",
"iam:DeleteRole",
"iam:UpdateRoleDescription",
"iam:CreateServiceLinkedRole",
"iam:UpdateRole",
"iam:DeleteServiceLinkedRole",
"iam:GetRolePolicy"
],
"Resource": "*",
"Condition": {
"BoolIfExists": {
"aws:MultiFactorAuthPresent": "true"
}
}
}
]
}
EDIT: 26/6/20
I tried to use Permission Boundaries as suggested, but perhaps my understanding is still insufficient. I made a new policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyAdmin",
"Effect": "Deny",
"Action": [
"iam:*"
],
"Resource": "*",
"Condition": {
"ArnEquals": {
"iam:PolicyArn": [
"arn:aws:iam::aws:policy/AdministratorAccess"
]
}
}
}
]
}
I would think that would mean Deny any/all iam actions when it concerns the AdministratorAccess Policy. However, the result is that all role assignments/creation are denied even when the policy being attached is NOT AdministratorAccess. However, if I setup a policy and add a Condition of ArnNotEquals the AdministratorAccess - then I seem to be able to do what I want(just using it as a policy, not as a Boundary)
Based on what I have seen, Permissions Boundary is probably the right way to go, but I cannot quite get it yet so I'm hesitant to mark it as "Correct Answer".
You can use AWS IAM Permissions Boundaries: Permissions Boundaries for IAM Entities - AWS Identity and Access Management
“A permissions boundary is an advanced feature for using a managed policy to set the maximum permissions that an identity-based policy can grant to an IAM entity. An entity's permissions boundary allows it to perform only the actions that are allowed by both its identity-based policies and its permissions boundaries.“
Here’s a step-by-step introduction on the AWS Security Blog: Delegate permission management to developers by using IAM permissions boundaries | AWS Security Blog
So using directions from John Rotenstein and finally realizing where I went wrong the way to get what I want is to add the following Permissions Boundary to the user:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "BoundaryAllowAllNotAdminAccess",
"Effect": "Allow",
"Action": "*",
"Resource": "*",
"Condition": {
"ArnNotEquals": {
"iam:PolicyArn": [
"arn:aws:iam::aws:policy/AdministratorAccess"
]
}
}
}
]
}
Where I went wrong was thinking that I need to Deny, but the Boundary is an AND restraint so I can allow all as long as it is not AdministratorAccess, then the other policies will give the actual actions/resources and AWS will allow as long as it doesn't use the AdministratorAccess.
I want to enable MFA in an AWS organization and allow users to manage only their own MFA device. But I want the users to be able to manage the device via the API/CLI (and not using the AWS Console).
I found this policy in the AWS documentation, which is almost good, as it allow to create/enable/delete its own MFAdevice:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowUsersToCreateEnableResyncDeleteTheirOwnVirtualMFADevice",
"Effect": "Allow",
"Action": [
"iam:CreateVirtualMFADevice",
"iam:EnableMFADevice",
"iam:ResyncMFADevice",
"iam:DeleteVirtualMFADevice"
],
"Resource": [
"arn:aws:iam::account-id-without-hyphens:mfa/${aws:username}",
"arn:aws:iam::account-id-without-hyphens:user/${aws:username}"
]
},
{
"Sid": "AllowUsersToDeactivateTheirOwnVirtualMFADevice",
"Effect": "Allow",
"Action": [
"iam:DeactivateMFADevice"
],
"Resource": [
"arn:aws:iam::account-id-without-hyphens:mfa/${aws:username}",
"arn:aws:iam::account-id-without-hyphens:user/${aws:username}"
],
"Condition": {
"Bool": {
"aws:MultiFactorAuthPresent": true
}
}
}
]
}
However, for device desactivation (iam:DeactivateMFADevice), it requires the condition aws:MultiFactorAuthPresent to be true. This is a sound security measure, the user can not disable MFA, without using MFA. But in this policy, when logged with MFA via API/CLI using STS and assuming a role, the resource "arn:aws:iam::account-id-without-hyphens:mfa/${aws:username}" does not represent the actual resource, as ${aws:username} is not present. I suppose that when using the AWS Console as a user, the boolean aws:MultiFactorAuthPresent can be true. But as far as I know, with API/CLI it is not possible to have both aws:MultiFactorAuthPresent==true and ${aws:username} present.
So, what policy could I write to authorize only the users to disable their device when using MFA, but when they assume a role ?
[disclaimer, this is to be used with the awless CLI]