Identity and access management frameworks enable administrators to define what an authorized person can -- and cannot -- do within a public cloud, such as AWS.
Amazon's native Identity and Access Management (IAM) service can apply policies to a specific user, but it can also assign a broader identity to any user or group for whom those policies and permissions are appropriate. For example, an admin could apply IAM roles to certain users that allows temporary access to resources or services the users might not otherwise interact with.
However, when you create a complex web of permissions and policies, you can run into maintenance challenges that lead to errors and oversights -- as well as potential security vulnerabilities. Automation can help reduce these issues.
An introduction to service-linked IAM roles
AWS provides service-linked IAM roles, which can help streamline the permissions process. These roles enable admins to predefine trust policies and permissions for specific services. When an AWS user invokes a service, such as Amazon Elasticsearch Service, AWS automatically links the corresponding role to that service. In addition to reducing vulnerabilities and management overhead, this process speeds service configuration.
An admin can apply service-linked roles to a variety of compute tools and services, such as AWS Elastic Beanstalk, Amazon Elastic Container Service and Elastic Load Balancing. Several database services also provide support for service-linked IAM roles, including Amazon DynamoDB, Amazon Redshift and Amazon Relational Database Service.
Admins don't typically need to create, edit or delete service-linked roles; AWS automatically creates them as long as the user has permissions for the Create Service Linked Role action. However, if the linked role is deleted, the admin can automatically recreate the role or create it manually via the IAM console, AWS Command Line Interface (CLI) or IAM API.
Once a service-linked role exists, the admin cannot edit it, but he or she can often change descriptions of the service to assist with role documentation or organization. When the service is no longer needed, manually delete the service role.
Manage your roles
While AWS service-linked IAM roles are highly automated and well-defined, there are some tactics that provide better insight into how to manage linked roles and their actions.
Check the IAM Roles page of the console to determine which services implement service-linked roles. The resulting table's Trusted entities column will display service-linked roles.
But currently, only a minority of AWS' vast suite of services supports this type of role. When a service in use adds support for service-linked roles, admins receive a message that indicates a new role has appeared in the AWS account. In most cases, this requires no specific action or response, but admins can use the IAM console to verify the service now uses service-linked roles.
It might seem undesirable to allow AWS to add roles, especially where they count toward IAM roles limits in an AWS account. However, service-linked roles can exceed the account role limit without penalties. Don't just delete the new role from the account, as that could remove important permissions and prevent the service from functioning properly.
Every IAM entity, such as a user, group or role, needs permissions to interact with service-linked roles. If you encounter problems when users access or interact with service-linked roles, overlooked permissions are often the problem. Verify that proper permissions are set to take care of this potential issue.
For example, you must have the proper permissions to allow a user, group or other role to create, edit or delete one or more service-linked roles. Set policy permissions with Effect, Action, Resource and Condition statements.
Track actions in CloudTrail
As they monitor and manage public cloud utilization, admins must also oversee and audit the activities that take place within AWS -- especially when the provider automatically performs certain actions, such as the creation of a service-linked role.
Once an admin verifies the newly created service-linked role, the entities that can assume the role, the permissions for the role and the actions for the role, let the service run. Use CloudTrail to review the actions performed by the desired service. In the CloudTrail console, choose Trails, and then select the corresponding S3 bucket that stores those logs. The logs show what happens when a desired service assumes a service-linked role to take actions. Check these behaviors for unexpected or undesirable results.
Set minimum role session time
AWS allows IAM entities to temporarily assume a role through AWS Security Token Service, AssumeRole API or the AWS assume-role command in CLI. The role duration can last anywhere from 15 minutes to 12 hours.
However, it is a good idea to set the role duration to the minimum practical duration to remain consistent with the principle of least privilege. Limit the maximum session time to less than 12 hours. When AWS users are unable to assume a role, it's most likely because the request duration exceeds the 12-hour maximum or the request exceeds the limit imposed by the AWS account owner.
Delete unneeded roles
It is sometimes advisable to delete service-linked IAM roles to revoke the permissions of a service -- usually to limit or exercise better control over an account's resources. But AWS performs a cross-check to prevent accidental deletions.
You can perform this deletion process through the IAM console. Open the console, and select Roles. Select the service-linked role to delete, and then select Delete role. Confirm the deletion, and IAM will check for the use of resources that require the service-linked role. If no resources need the role, it completes the deletion. If resources do require the role, the deletion fails, and IAM offers details about why it could not complete. To finish deleting a service-linked role, first delete any listed resources that use it. However, the actual deletion process varies according to the individual AWS resource or service.