AWS Certified Advanced Networking Series: VPC Pt5 (IAM Roles)
In this topic its about IAM access, credentials & permissions the users will have over the resources.
IAM roles
An IAM role is an entity within the AWS account that has specific permissions.
Using temporary credentials
· Temporary credentials can be used to sign in with federation, assume an IAM role, or to assume a crossaccount role. To obtain temporary security credentials by calling AWS STS API operations such as AssumeRole or GetFederationToken.
· Amazon VPC supports using temporary credentials.
Service-linked roles
Service-linked roles allow AWS services to access resources in other services to complete an action on your behalf. Service-linked roles appear in the IAM account and are owned by the service. An IAM administrator can view but not edit the permissions for service-linked roles.
Transit gateways support service-linked roles.
Service roles
This feature allows a service to assume a service role on your behalf. This role allows the service to access resources in other services to complete an action on your behalf.
Service roles appear in the IAM account and are owned by the account. This means that an IAM administrator can change the permissions for this role.
However, doing so might break the functionality of the service. Amazon VPC supports service roles for flow logs. When a flow log is created, it’s a must to choose a role that allows the flow logs service to access Cloudwatch logs.
Amazon VPC policy examples
· By default, IAM users and roles don’t have permission to create or modify VPC resources.
· They also can’t perform tasks using the AWS Management Console, AWS CLI, or AWS API.
· An IAM administrator must create IAM policies that grant users and roles permission to perform specific API operations on the specified resources they need.
· The administrator must then attach those policies to the IAM users or groups that require those permissions.
Policy best practices
Identity-based policies are very powerful. It can determine whether someone can create, access, or delete Amazon VPC resources in the account. These actions can incur costs for the AWS account. Follow these guidelines and recommendations when creating or editing identity-based policies,
Get Started Using AWS Managed Policies — To start using Amazon VPC quickly, use AWS managed policies to give employees the permissions they need. These policies are already available in the account and are maintained and updated by AWS.
• Grant Least Privilege — When creating custom policies, grant only permissions required to perform a task. Start with a minimum set of permissions and grant additional permissions, as necessary. Doing so is more secure than starting with permissions that are too lenient and then trying to tighten them later.
• Enable MFA for Sensitive Operations — For extra security, require IAM users to use multi-factor authentication (MFA) to access sensitive resources or API operations.
• Use Policy Conditions for Extra Security — To the extent that it’s practical, define the conditions under which the identity-based policies allow access to a resource. For example, write conditions to specify a range of allowable IP addresses that a request must come from. Write conditions to allow requests only within a specified date or time range, or to require the use of SSL or MFA.
Viewing the Amazon VPC console
· To access the Amazon VPC console, its required to have a minimum set of permissions.
· These permissions must allow to list and view details about the Amazon VPC resources in the AWS account.
· When creating an identity-based policy that is more restrictive than the minimum required permissions, the console won’t function as intended for entities (IAM users or roles) with that policy.
Note: You don’t need to allow minimum console permissions for users that are making calls only to the AWS CLI or the AWS API. Instead, for those users, allow access only to actions that match the API operation that they need to perform.
Allow users to view their own permissions
This example shows how you might create a policy that allows IAM users to view the inline and managed policies that are attached to their user identity. This policy includes permissions to complete this action on the console or programmatically using the AWS CLI or AWS API.
Create a VPC with a public subnet
The following example enables users to create VPCs, subnets, route tables, and internet gateways. Users can also attach an internet gateway to a VPC and create routes in route tables. The ec2:ModifyVpcAttribute action enables users to enable DNS hostnames for the VPC, so that each instance launched into a VPC receives a DNS hostname.
The preceding policy also enables users to create a VPC using the first VPC wizard configuration option in the Amazon VPC console. To view the VPC wizard, users must also have permission to use the ec2:DescribeVpcEndpointServices. This ensures that the VPC endpoints section of the VPC wizard loads correctly.
Modify and delete VPC resources
Control which VPC resources users can modify or delete. For example, the following policy allows users to work with and delete route tables that have the tag Purpose=Test. The policy also specifies that users can only delete internet gateways that have the tag Purpose=Test. Users cannot work with route tables or internet gateways that do not have this tag.
Managing security groups
Following policy grants users permission to create and delete inbound and outbound rules for any security group within a specific VPC. The policy does this by applying a condition key (ec2:Vpc) to the security group resource for the Authorize and Revoke actions.
The second statement grants users permission to describe all security groups. This enables users to view security group rules in order to modify them.
To view security groups on the Security Groups page in the Amazon VPC console, users must have permission to use the ec2:DescribeSecurityGroups action. To use the Create security group page, users must have permission to use the ec2:DescribeVpcs and ec2:CreateSecurityGroup actions.
The following policy allows users to view and create security groups. It also allows them to add and remove inbound and outbound rules to any security group that’s associated with vpc-11223344556677889.
To allow users to change the security group that’s associated with an instance, add the ec2:ModifyInstanceAttribute action to your policy. Alternatively, to enable users to change security groups for a network interface, add the ec2:ModifyNetworkInterfaceAttribute action to your policy.
Launching instances into a specific subnet
The following policy grants users permission to launch instances into a specific subnet, and to use a specific security group in the request. The policy does this by specifying the ARN for subnet-11223344556677889, and the ARN for sg-11223344551122334. If users attempt to launch an instance into a different subnet or using a different security group, the request will fail (unless another policy or statement grants users permission to do so).
The policy also grants permission to use the network interface resource. When launching into a subnet, the RunInstances request creates a primary network interface by default, so the user needs permission to create this resource when launching the instance.
Launching instances into a specific VPC
The following policy grants users permission to launch instances into any subnet within a specific VPC. The policy does this by applying a condition key (ec2:Vpc) to the subnet resource.
The policy also grants users permission to launch instances using only AMIs that have the tag “department=dev”.
Additional Amazon VPC policy examples
Additional example IAM policies related to Amazon VPC in the following topics:
• ClassicLink
• Traffic mirroring
• Transit gateways
• VPC endpoints and VPC endpoint services
• VPC endpoint policies
• VPC Peering
