AWS Certified Advanced Networking Series: VPC Pt3
Continuing Security in Amazon Virtual Private Cloud…
Internetwork traffic privacy in Amazon VPC
Security groups: Works like a firewall for instances that is associated by controlling both inbound and outbound traffic at the instance level. During launching an instance, it can be associated with one or more security groups that has been created or can be created during the launch.
Each instance in the VPC could belong to a different set of security groups. If it’s the security group is not specified when an instance is launched, the instance is automatically associated with the default security group for the VPC.
• Network access control lists (ACLs): Network ACLs act as a firewall for associated subnets, controlling both inbound and outbound traffic at the subnet level.
• Flow logs: Flow logs capture information about the IP traffic going to and from network interfaces in the VPC. Flow log can be created for VPC, subnet, or individual network interface. Flow log data is published to CloudWatch Logs or Amazon S3, it can help to diagnose overly restrictive or overly permissive security group and network ACL rules.
• Traffic mirroring: AWS allows copying network traffic from an elastic network interface of an Amazon EC2
instance & sending the traffic to out-of-band security and monitoring appliances.
· AWS Identity and Access Management (IAM) can be used to control permission to create and manage security groups, network ACLs, and flow logs. For example, network administrators will have such permission, but not give permission to personnel who only need to launch instances.
· Amazon security groups and network ACLs don’t filter traffic to or from link-local addresses (169.254.0.0/16) or AWS reserved IPv4 addresses (these are the first four IPv4 addresses of the subnet, including the Amazon DNS server address for the VPC). Similarly, flow logs do not capture IP traffic to or from these addresses. These addresses support the following:
• Domain Name Services (DNS)
• Dynamic Host Configuration Protocol (DHCP)
• Amazon EC2 instance metadata
• Key Management Server (KMS) — license management for Windows instances
• Routing in the subnet
Additional firewall can be implemented in the instance to block network-communication with link-local addresses.
This diagram illustrates security layers by security groups and network ACLs. For example, traffic from an internet gateway is routed to the appropriate subnet using the routes in the routing table. The rules of the network ACL that is associated with the subnet control which traffic is allowed to the subnet. The rules of the security group that is associated with an instance control which traffic is allowed to the instance.
Instances can only be secured by using security groups. Network ACLs can be an additional layer of defense.
The next sub-section in Security would be
Identity and access management (IAM) for Amazon VPC
· IAM is a service an Administrator can use to securely control access to AWS resources.
· IAM administrators control who can be authenticated (signed in) and authorized (have permissions) to use Amazon VPC resources.
· IAM can be used without any additional charges.
Service user — A user that works by using Amazon VPC service will be provided the credentials and permissions by the administrator. The user might require additional permissions for certain work. Therefore it’s best for the user to understand how access is managed to request the right permissions from the administrator.
Service administrator — This role oversees Amazon VPC resources in an organization & usually have full access to it. This role will determine the Amazon VPC features and resources employees require access to. The requests will be sent to the administrator to change the permissions for the changes to take place.
IAM administrator — Its best to learn details about writing policies to manage access to Amazon VPC.
AWS Account Root User
· New account creation starts with a single sign-in identity that has complete access to all AWS services and resources in the account.
· This identity is called the AWS Account root user & is accessed by signing in with email & password that is used to create the account. Strongly recommended not to use it for everyday tasks.
· Best practice is to use it to create first IAM User
· Securely lock away the root user credentials and use them to perform only a few account and service management tasks.
IAM users and groups
· A user is uniquely associated with one person or application. Users have permanent long-term credentials.
· IAM user is an identity that has specific permissions for a single person or application.
· IAM users can have credentials such as user name & password or a set of access keys. It is advised to store the access key safely as it cannot be recovered & must generate new access key pair.
· IAM Group is a identity that specifies a collection of IAM users. Users can’t sign up as a group.
· It is used that has specific permissions for a single person or application.
· It makes that has specific permissions for a single person or application.
· For example, a group named IAMAdmins and give that group permissions to administer IAM resources.
· A role is intended to be assumable by anyone who needs it. A role provides temporary credentials.
· IAM Role is an identity that has specific permissions.
· It is similar to an IAM user, but is not associated with a specific person
· IAM Role can be temporarily assumed by switching roles in AWS Management Console.
· Roles can be assumed by calling an AWS CLI or AWS API operation or by using a custom URL.
IAM roles with temporary credentials are useful in the following situations:
• Temporary IAM user permissions — An IAM user can assume an IAM role to temporarily take on
different permissions for a specific task.
• Federated user access — Instead of creating an IAM user, you can use existing identities from AWS Directory Service, your enterprise user directory, or a web identity provider. These are known as federated users. AWS assigns a role to a federated user when access is requested through an identity provider.
• Cross-account access — You can use an IAM role to allow someone (a trusted principal) in a different account to access resources in your account. Roles are the primary way to grant cross-account access. However, with some AWS services, you can attach a policy directly to a resource (instead of using a role as a proxy).
• AWS service access — It is a service role which has the authority to perform actions on behalf of the account holder in order to process or complete a task. This role can be created, modified and deleted using IAM and must be provided all the permissions that is required by the service to access the AWS resources that it needs. It varies from service to service however many services allow to select permission as long the required documentations are provided. Service roles provide access only within the account and cannot be used to grant access to services in other accounts. For example, a role can be created to allow Amazon Redshift to access an Amazon S3 bucket on behalf of the account holder and then load data from that bucket into an Amazon Redshift cluster.
• Applications running on Amazon EC2 — IAM role can be used to manage temporary credentials for applications that are running on an EC2 instance and making AWS CLI or AWS API requests. Preferable to storing access keys within the EC2 instance. To assign an AWS role to an EC2 instance and make it available to all of its applications, create an instance profile that is attached to the instance. An instance profile contains the role and enables programs that are running on the EC2 instance to get temporary credentials.
The Journey Continues…
I’m stopping at IAM Roles & will continue with Managing access using policies. Security is one of the huge topics in AWS so it has many subtopics as well as detail information that is crucial for the examination.