Advanced Permissions and Accounts Flashcards
STS generates these when the sts:AssumeRole API call is made
Temporary credentials
STS credentials are similar to secret/access keys except for these 2 thigns
Don’t below to the identity that assumes the role (unlike IAM user)
Temporay (they expire)
The trust policy on a role defines this
Who is allowed to assume the role
The permissions policy on a role defines this
The AWS services and actions the role gives access to
STS creds includ these 4 items
AccessKeyId -unique identifier
Expiration
SecretAccessKey - Used to sign requests
Session Token - unique token that must come along with all requests.
sts:AssumeRole* calls are made by existing identities of either one of these two types
AWS Identity
External(Federation) Identity
Are roles meant to have complex logic determining who gets what set of permissions?
No, a role gives a set of permissions to anyone who is enabled to assume in the trust policy. Different set of permissions implies a different role is needed.
If you knew of a crediential leak for a role, why wouldn’t you remove all permissions of that role or just delete the role outright?
There may be other users who assume the role that still need the access.
If you knew of a credential leak for a role, why would you not change the trust policy for the role to limit the access?
The malicous user already has valid credentials (Access key, secret key, token) to assume the role. In essence, the cat is already out of the bag.
Can you manually invalidate temporary credentials like roles?
No, but you can update the role permissions policy with an inline DENY of AWSRevokeOlderSessions for any sessions older than now. Valid users will be forced to re authenticate, bad actor will be SOL.
When does the session token come into play for AWS creds?
Any temporary credentials
First step in interpreting a policy doc?
Identify the number of Statement block {Effect:…..}
What implicit permissions exist if nothing is defined?
Nothing. Said another way, implicit deny
What always takes precident in AWS?
Deny permission
When looking a Resource in a policy statement detailing with S3, what does /* represent?
Sub-objects, not the bucket itself
Why is it unlikely that you will find a policy with only a deny statement?
By default, everything is denied anway.
What S3 actions require a * resource?
ListAllMyBuckets
GetBucketLocation
CreateBucket
Only these types of permissions are impacted by Permissions Boundaries
Identity permissions (any resource policies are applied in full)
Permissions Boundaries can only be applied to these two things
IAM Users
IAM Roles
Do permissions boundaries grant access on their own?
No, they define maximum permissions an identity can have.
Common Variables to use in IAM
aws: CurrentTime This can be used for conditions that check the date and time.
aws: EpochTime This is the date in epoch or Unix time, for use with date/time conditions.
aws: TokenIssueTime This is the date and time that temporary security credentials were issued and can be used with date/time conditions. Note: This key is only available in requests that are signed using temporary security credentials. For more information about temporary security credentials, see Temporary security credentials in IAM.
aws: PrincipalType This value indicates whether the principal is an account, user, federated, or assumed role—see the explanation that follows later.
aws: SecureTransport This is a Boolean value that represents whether the request was sent using SSL.
aws: SourceIp This is the requester’s IP address, for use with IP address conditions. Refer to IP address condition operators for information about when SourceIp is valid and when you should use a VPC-specific key instead.
aws: UserAgent This value is a string that contains information about the requester’s client application. This string is generated by the client and can be unreliable. You can only use this context key from the AWS CLI.
aws: userid This value is the unique ID for the current user—see the chart that follows.
aws: username This is a string containing the friendly name of the current user—see the chart that follows.
ec2: SourceInstanceARN This is the Amazon Resource Name (ARN) of the Amazon EC2 instance from which the request is made. This key is present only when the request comes from an Amazon EC2 instance using an IAM role associated with an EC2 instance profile.
What to things have to happen for an entity in Account A to access something in Account B?
Account A has to allow the access out, account B has to allow the access to the resource.
If an SCP is in place, what happens if an incoming action is not allowed?
Implicitly denied
Six checkpoints of resource access
Explict Deny
SCPs
Resource Policies (if access granted here, stop processing)
Permission Boundaries
Session Policies (for IAM Roles)
Identity Policies
What is the S3 Canonical ID?
Legacy ID used in ACLs
What level do you define in the trust relationship of a role?
The account level that you will permit to use the role.
There levels of an AWS Org that SCPs can be attached to
Root level of the org (entire)
1 to many OUs
Individual account level
IN an AWS organization, how to you apply an SCP so it impacts the root AWS account/management account?
You cannot. It is special.
Do SCPs grant permissions?
No, they are account level permissions boundaries. They limit what can be done in an AWS account, not grant access.
Can you limit what the root account in an AWS account can do?
Not exactly, but you can use SCP’s to limit what can be done in an AWS account, inherintly limiting what the root account can do.
What is the default SCP setting when enabled?
Allow *. If you didn’t do this, the default implicit deny would apply at the SCP level, and there would be no access.
From an SCP perspective, how do you 1) implement a deny list approach 2)implement an allow list approach and 3) why
1) Keep the default allow *, use deny statements for services you want to block
2) Remove the default allow, add allow statements for services you want
3) 1 is easier admin overhead
Can you apply an S3 ACL to multiple objects?
No, each object needs an ACL (no inheritance)
In S3, who becomes the object owner of an S3 object?
The source account of the thing uploading the object
Using ACLs and S3 in a cross account scenario does the destination account get access by default to the object uploaded by the souce?
No, this is a limitation of ACLs. Destination bucket account will only have access if the source entity granted access.
Why might you choose to use Cross Account Roles when granting an external party access to store objects in S3?
That way the object owner of the S3 objects will be your account.