In this video on AWS cloud security, Jeff Winesett discusses the IAM service. IAM manages users, groups, roles and permissions for an AWS account and is always the responsibility of the AWS customer to define and keep secure.
- [Instructor] When discussing the shared security model in the previous section, there was one area that remains the responsibility of the customer regardless of the service category. This is the customer account roles permissions and access configuration. IAM is short for identity and access management. It is a management service provided by Amazon that allows control of the access and permissions to the AWS resources and services in an account. It's important to understand some of the basics of IAM.
When a new AWS account is initially set up, what has been created is what is referred to as the master account. The initial first user created and associated with this account is the master user. This is a little like root on a Unix-based operating system. This master user has access to everything, including all of the billing information. It makes sense to keep this master account secure. It is recommended not to use this master account for continued access to services and resources.
Instead, IAM should be used to set up the appropriate access control structures. It is also strongly recommended to use multifactor authentication on this master account for added security. IAM provides the ability to manage access control entities such as users, groups, roles, and permissions. These varying access entities are created and then applied to individual services and API calls.
This allows permissions to be defined that control which users can access which specific services, which actions they can perform within these services, and which resources are available within these services. When using IAM to create new users, the newly created user has no access granted by default. This adheres to the security principle of least privileged, which specifies that a user or resource should only have the minimum permissions necessary to carry out and perform their responsibilities.
Having the user start with absolutely no permissions helps to only apply the appropriate permissions required for the user to fulfill their specific tasks. There are different credential types that a user may need. If they need access to the console, they will need login credentials. And if they'll be using the API to interface with services, they'll need an access key. Permissions are assigned either individually to the user or by placing the user within a group that has certain permissions defined.
IAM can also be used to create groups. Groups are composed of a set of one or more permissions. Once defined, users are added to these groups, which allows permissions to be managed on a group level rather than on an individual by individual basis. Roles can also be created. An IAM role is similar to a user. It is an AWS identity with permission policies that determine access in AWS. However, instead of being uniquely associated with one person, a role is intended to be assumed by any resource that requires it.
Also, a role does not have any fixed login, nor fixed API access credentials associated with it. Instead, whenever a role is assumed, necessary access keys are created dynamically and provided to the user or service that assumed the role. When a role is created, one or more access permissions are assigned to that role. A role is more or less this set of access permissions. Whenever a user or service assumes the role, they then have access to these permissions while they are using the role.
Any other permissions that may have been previously defined for that user or resource, for example, specific to the user or group, are temporarily suspended while the role is assumed. Only the permissions associated with the role are allowed when a user or service is using a role. IAM roles allow users or services that otherwise don't normally have access to resources to act on behalf of the account owner. IAM users or AWS services can assume a role to obtain temporary security credentials that can be used to make AWS API calls.
By using roles, credentials don't have to be shared and permissions don't have to be defined for each entity that requires access to a resource. For example, say a business is using an external offender to temporarily help troubleshoot some application problem. This vendor would likely need access to a few services in that business's AWS account. Rather than create a new IAM user for the external vendor to use, thereby providing them with explicit security credentials to access the account, a role can be used.
Using IAM, a role can be created for the vendor to assume. And when using this role to access the business's account, they will only have access to the permissions assigned to that role. Using roles for this purpose provides much less administrative overhead than creating new users and groups for this use case. Roles also simplify the permissions needed by applications running on EC2, which may require access to other AWS resources.
To grant applications on EC2 instance access to AWS resources, a role can be created with the required permissions and then the EC2 instance can launch itself into that role. This, then, embeds the needed access keys into the instance metadata. Applications can access this metadata on the instance to retrieve the access they need, allowing applications to assume these roles provides better security than providing long-term dedicated access credentials to each application.
Keeping things secure, lesson number two, never use the master account for routine access to resources or to manage your services. Create separate users, groups, roles, and permissions in IAM and only allow access when absolutely needed and only to the specific resources that are needed.
- Benefits of cloud services
- Making architectures scalable
- Examining cloud constraints
- Virtual servers, EC2, and Elastic IP
- Using the Amazon machine image
- Elastic load balancing
- Using CloudWatch for monitoring
- Security Models
- Elastic block storage
- S3, CloudFront, and Elastic Beanstalk
- Handling queues, workflows, and notifications
- Caching options and services
- Identity and access management
- Creating a custom server image
- Application deployment strategies
- Serverless architectures