Evaluating IAM policy types for given requirements and workloads

Can you describe the difference between identity-based policies and resource-based policies in AWS IAM?

Identity-based policies are attached to IAM users, groups, or roles, specifying permissions for those entities. These policies allow or deny actions on AWS resources. Resource-based policies, on the other hand, are attached directly to AWS resources and specify which principals (users, accounts, roles) can or cannot access that resource.

When would you use a managed policy rather than an inline policy in an IAM role?

Managed policies are best used when you want to have reusable, centrally managed policy objects that can be attached to multiple users, groups, or roles. It’s beneficial for consistent policy deployment across an organization. Inline policies are used when a policy is strictly intended for a single user, group, or role, and you want the policy’s lifecycle to be tied to that specific identity.

What is the significance of using conditions in IAM policies?

Conditions in IAM policies add an extra layer of security by defining requirements that must be met for a policy statement to take effect. They can be based on various factors like IP address, time of day, or multi-factor authentication, and are crucial for fine-grained access control.

How would you design an IAM policy to allow a user access only during work hours in their specific timezone?

This policy would use a condition that restricts access based on the current time. An example condition using the DateGreaterThan and DateLessThan condition operators could specify the allowed access times within the user’s workday, making sure to adjust for the timezone offset as necessary.

What AWS IAM feature would you use to ensure that policies do not allow unintentional access to all resources in an account?

AWS IAM policy conditions can be used to prevent overly permissive actions. For example, using specific resource ARNs in policies, setting condition keys like aws:ResourceTag to enforce tag-based access control, or using SCPs (Service Control Policies) in AWS Organizations to ensure account-level boundaries are some of the ways to prevent unintentional access to all resources.

How can you use IAM policies together with resource tagging to manage permissions across different projects or departments?

By implementing a resource tagging strategy and using the aws:ResourceTag condition key in your IAM policies, you can align permissions with specific project or department tags, thus granting access only to the resources with matching tags.

Why might you opt to use temporary security credentials (e.g., those provided by STS) over long-term access keys for an IAM user when accessing AWS services programmatically?

Temporary security credentials provided by AWS Security Token Service (STS) are more secure than long-term access keys as they are automatically rotated and have a limited lifespan. They also provide options for enhanced security by allowing the requesting entity to assume an IAM role with the exact permissions needed for the task, reducing the risk associated with compromised credentials.

Describe how you would address the need for a user to assume different IAM roles depending on the task or service they are interacting with.

By implementing IAM role switching, you can grant a user the ability to change to different IAM roles within the same or different AWS accounts. Each IAM role would have a separate set of permissions tailored to specific tasks or services, controlled by the trust policy attached to the role. The user can then use the AssumeRole API to switch between these roles as needed.

In what scenarios would you advise using service-linked roles?

Service-linked roles are designed for AWS services to perform actions on your behalf. They should be used when you need to grant an AWS service permissions to manage resources within your account. These roles have predefined policies and trust relationships set by the service, making them secure and easy to manage.

How might cross-account access be configured with IAM policies, and what are some security considerations to keep in mind?

Cross-account access is configured by creating a role in the target account with a policy that grants the necessary permissions. The trust relationship of the role is updated to allow the principal (user, role) of the source account to assume the role using sts:AssumeRole. When setting up cross-account access, it’s important to scope down permissions as much as possible, monitor logs for unusual activity, and regularly review permissions for any changes in requirements.

Can you provide an example of when you would use inline policies over managed policies?

Inline policies are useful when you need to create a policy that is designed to be exclusively associated with a single IAM user, group, or role, and you want the lifecycle of that policy to be tightly coupled with that IAM entity. For instance, you might use an inline policy when you need to ensure that specific permissions are retired as soon as a user or role is deleted.

How does AWS IAM help in enforcing multi-factor authentication (MFA) for sensitive operations, and what would a policy enforcing MFA look like?

AWS IAM can enforce MFA by including condition keys in policies that require MFA authentication. A condition like “aws:MultiFactorAuthPresent”: “true” can be used within a policy statement to ensure that certain actions can only be performed if the user is authenticated with MFA. This increases the security for sensitive operations by adding an additional layer of authentication.