Tag: AWS IAM

To govern federated access to your AWS resources, it’s a common practice to use Microsoft Active Directory (AD) groups. When using AD groups, establishing federation requires the number of AD groups to be equal to the number of your AWS accounts multiplied by the number of roles in each of your AWS accounts. As you can imagine, this can result in the creation of a very large number of AD groups to manage federated access.

However, some organizations have limits on how many AD groups they can create. For example, an organization might need to keep its AD group hierarchy reasonably flat and avoid a deep nesting of groups. Such a situation needs a solution that doesn’t require you to create exponentially more AD groups while still allowing you to use access control and automated user integration.

In this blog post, I provide step-by-step instructions for integrating AWS Identity and Access Management (IAM) with Microsoft Active Directory Federation Services (AD FS) by using AD user attributes, allowing you to establish federated access without expanding your total number of AD groups. Your organization’s enterprise administrator probably has existing processes in place for managing AD group memberships and provisioning, and you can extend these processes to the management of AD user attributes and the reduction of your organization’s dependency on AD groups. (more…)

To help you grant access to specific resources and conditions, the Example Policies page in the AWS Identity and Access Management (IAM) documentation now includes more than thirty policies for you to use or customize to meet your permissions requirements. The AWS Support team developed these policies from their experiences working with AWS customers over the years. The example policies cover common permissions use cases you might encounter across services such as Amazon DynamoDB, Amazon EC2, AWS Elastic Beanstalk, Amazon RDS, Amazon S3, and IAM.

In this blog post, I introduce the updated Example Policies page and explain how to use and customize these policies for your needs.

The new Example Policies page

The Example Policies page in the IAM User Guide now provides an overview of the example policies and includes a link to view each policy on a separate page. Note that each of these policies has been reviewed and approved by AWS Support. If you would like to submit a policy that you have found to be particularly useful, post it on the IAM forum. (more…)

As part of the AWS Shared Responsibility Model, you are responsible for monitoring and managing your resources at the operating system and application level. When you monitor your application servers, for example, you can measure, visualize, react to, and improve the security of those servers. You probably already do this on premises or in other environments, and you can adapt your existing processes, tools, and methodologies for use in the AWS Cloud. For more details about best practices for monitoring your AWS resources, see the “Manage Security Monitoring, Alerting, Audit Trail, and Incident Response” section in the AWS Security Best Practices whitepaper.

This blog post focuses on how to log and create alarms on invalid Secure Shell (SSH) access attempts. Implementing live monitoring and session recording facilitates the identification of unauthorized activity and can help confirm that remote users access only those systems they are authorized to use. With SSH log information in hand (such as invalid access type, bad private keys, and remote IP addresses), you can take proactive actions to protect your servers. For example, you can use an AWS Lambda function to adjust your server’s security rules when an alarm is triggered that indicates an invalid SSH access attempt.

In this post, I demonstrate how to use Amazon CloudWatch Logs to monitor SSH access to your application servers (Amazon EC2 Linux instances) so that you can monitor rejected SSH connection requests and take action. I also show how to configure CloudWatch Logs to send SSH access logs from application servers that reside in a public subnet. Last, I demonstrate how to visualize how many attempts are made to SSH into your application servers with bad private keys and invalid user names. Using these techniques and tools can help you improve the security of your application servers.

(more…)

Coming soon, AWS will improve the way you sign in to your AWS account. Whether you sign in as your account’s root user or an AWS Identity and Access Management (IAM) user, you will be able to sign in from the AWS Management Console’s home page. This means that if you sign in as an IAM user, you will no longer be required to use an account-specific URL. However, the account-specific URL you use to sign in today will continue to work.

In the new sign-in experience, you can sign in from the homepage using either your root user’s or IAM user’s credentials. In the first step, root users will enter their email address; IAM users will enter their account ID (or account alias). In the second step, root users will enter their password; IAM users will enter their user name and password.

In this blog post, I explain the improvements that are coming soon to the way you sign in to your AWS account as a root user or IAM user. If you use a password manager to help you sign in to AWS, you may need to make updates so that it will work with the new sign-in experience. (more…)

Today, the Resource Groups Tagging API introduced a pagination parameter to the GetResources action that makes it easier for you to manage lists of resources returned by your queries. Using this parameter, you can list your resources that are associated with specific tags or resource types, and limit result sets to a specific number per page. Previously, you could list resources only by the number of tags.

Let’s say you want to query your resources that have tags with the key of “stage” and the value of “production”. You want to return as many as 25 resources per page of results. The following Java code example meets those criteria.

TagFilter tagFilter = new TagFilter();
tagFilter.setKey("stage");
tagFilter.setValues(Arrays.asList(new String[] { "production" }));

List<TagFilter> tagFilters = new ArrayList<>();
tagFilters.add(tagFilter);

AWSResourceGroupsTaggingAPIClient client = new AWSResourceGroupsTaggingAPIClient();
GetResourcesRequest request = new GetResourcesRequest();
request.withResourcesPerPage(25).withTagFilters(tagFilters);
GetResourcesResult result = client.getResources(request);

Also, with the updated AWS CLI, the GetResources action by default returns all items that meet your query criteria.  If you want to use pagination, the AWS CLI continues to support the case in which you receive a subset of items returned from a query and a pagination token for looping through the remaining items.

For example, the following AWS CLI script uses automatic pagination to return all resources that meet the query criteria.

aws resourcegroupstaggingapi get-resources

However, if you want to return resources in groups of 25, the following AWS CLI script example uses custom pagination and returns as many as 25 resources per page that meet the query criteria.

aws resourcegroupstaggingapi get-resources –-resources-per-page 25

If you have comments about this post, submit them in the “Comments” section below. Start a new thread on the Resource Groups Tagging API forum if you have questions about or issues using the new functionality.

– Nitin

As of May 15, 2017, you can define AWS Identity and Access Management policies to control which Auto Scaling resources users can access and the actions users are permitted to perform on those resources. Auto Scaling helps you maintain application availability and allows you to scale your Amazon EC2 capacity up or down automatically according to conditions you define.

With resource-level permissions, you can enable different users within an organization, such as application developers and IT specialists, to access and modify launch configurations and Auto Scaling groups with appropriately configured permissions.

To learn more, see the full What’s New announcement.

– Craig

Some AWS services create and manage AWS resources on your behalf. To do this, these services require you to delegate permissions to them by using AWS Identity and Access Management (IAM) roles. Today, AWS IAM introduces service-linked roles, which give you an easier and more secure way to delegate permissions to AWS services. To start, you can use service-linked roles with Amazon Lex, a service that enables you to build conversational interfaces in any application by using voice and text. Over time, more AWS services will use service-linked roles as a way for you to delegate permissions to them to create and manage AWS resources on your behalf. In this blog post, I walk through the details of service-linked roles and show how to use them.

Creation and management of service-linked roles

Each service-linked role links to an AWS service, which is called the linked service. Service-linked roles provide a secure way to delegate permissions to AWS services because only the linked service can assume a service-linked role. Additionally, AWS automatically defines and sets the permissions of service-linked roles, depending on the actions that the linked service performs on your behalf. This makes it easier for you to manage the permissions you delegate to AWS services. AWS allows only those changes to service-linked roles that do not remove the permissions required by the linked service to manage your resources, preventing you from making any changes that would leave your AWS resources in an inconsistent state. Service-linked roles also help you meet your monitoring and auditing requirements because all actions performed on your behalf by an AWS service using a service-linked role appear in your AWS CloudTrail logs.

When you work with an AWS service that uses service-linked roles, the service automatically creates a service-linked role for you. After that, whenever the service must act on your behalf to manage your resources, it assumes the service-linked role. You can view the details of the service-linked roles in your account by using the IAM console, IAM APIs, or the AWS CLI.

Service-linked roles follow a specific naming convention that includes a mandatory prefix that is defined by AWS and an optional suffix defined by you. The examples in the following table show how the role names of service-linked roles may appear. (more…)

Join us in San Francisco for AWS IAM Day on Thursday, March 23, from 9:30 A.M.–4:15 P.M. At this free technical event, we will introduce you to AWS Identity and Access Management (IAM) concepts using easy-to-follow examples, and tools and strategies you can use for controlling access to your AWS environment. We will also cover how to integrate Active Directory with AWS workloads and how to enable your federated users to authenticate into AWS by using your organization’s identity provider. You can attend one session or stay for the full day.

Learn more and register!

– Craig

AWS Identity and Access Management (IAM) roles enable your applications running on Amazon EC2 to use temporary security credentials. IAM roles for EC2 make it easier for your applications to make API requests securely from an instance because they do not require you to manage AWS security credentials that the applications use. Recently, we enabled you to use temporary security credentials for your applications by attaching an IAM role to an existing EC2 instance by using the AWS CLI and SDK. To learn more, see New! Attach an AWS IAM Role to an Existing Amazon EC2 Instance by Using the AWS CLI.

Starting today, you can attach an IAM role to an existing EC2 instance from the EC2 console. You can also use the EC2 console to replace an IAM role attached to an existing instance. In this blog post, I will show how to attach an IAM role to an existing EC2 instance from the EC2 console. (more…)

AWS Identity and Access Management (IAM) roles enable your applications running on Amazon EC2 to use temporary security credentials that AWS creates, distributes, and rotates automatically. Using temporary credentials is an IAM best practice because you do not need to maintain long-term keys on your instance. Using IAM roles for EC2 also eliminates the need to use long-term AWS access keys that you have to manage manually or programmatically. Starting today, you can enable your applications to use temporary security credentials provided by AWS by attaching an IAM role to an existing EC2 instance. You can also replace the IAM role attached to an existing EC2 instance.

In this blog post, I show how you can attach an IAM role to an existing EC2 instance by using the AWS CLI. (more…)