Tag: AWS CLI
The Resource Groups Tagging API Makes It Easier to List Your Resources by Using a New Pagination Parameter
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.
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.
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.
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.
Today, we updated the AWS Identity and Access Management (IAM) console to make it easier for you to create and manage your IAM users. These improvements include an updated user creation workflow and new ways to assign and manage permissions. The new user workflow guides you through the process of setting user details, including enabling programmatic access (via access key) and console access (via password). In addition, you can assign permissions by adding users to a group, copying permissions from an existing user, and attaching policies directly to users. We have also updated the tools to view details and manage permissions for existing users. Finally, we’ve added 10 new AWS managed policies for job functions that you can use when assigning permissions.
In this post, I show how to use the updated user creation workflow and introduce changes to the user details pages. If you want to learn more about the new AWS managed policies for job functions, see How to Assign Permissions Using New AWS Managed Policies for Job Functions.
How to Manage Secrets for Amazon EC2 Container Service–Based Applications by Using Amazon S3 and Docker
Docker enables you to package, ship, and run applications as containers. This approach provides a comprehensive abstraction layer that allows developers to “containerize” or “package” any application and have it run on any infrastructure. Docker containers are analogous to shipping containers in that they provide a standard and consistent way of shipping almost anything.
One of the challenges when deploying production applications using Docker containers is deciding how to handle run-time configuration and secrets. Secrets are anything to which you want to tightly control access, such as API keys, passwords, and certificates. Injecting secrets into containers via environment variables in the Docker run command or Amazon EC2 Container Service (ECS) task definition are the most common methods of secret injection. However, those methods may not provide the desired level of security because environment variables can be shared with any linked container, read by any process running on the same Amazon EC2 instance, and preserved in intermediate layers of an image and visible via the Docker inspect command or ECS API call. You could also bake secrets into the container image, but someone could still access the secrets via the Docker build cache.
In this blog post, I will show you how to store secrets on Amazon S3, and use AWS Identity and Access Management (IAM) roles to grant access to those stored secrets using an example WordPress application deployed as a Docker image using ECS. Using IAM roles means that developers and operations staff do not have the credentials to access secrets. Only the application and staff who are responsible for managing the secrets can access them. The deployment model for ECS ensures that tasks are run on dedicated EC2 instances for the same AWS account and are not shared between customers, which gives sufficient isolation between different container environments. (more…)
AWS Key Management Service (AWS KMS) allows you to use keys under your control to encrypt data at rest stored in Amazon S3. The two primary methods for implementing this encryption are server-side encryption (SSE) and client-side encryption (CSE). Each method offers multiple interfaces and API options to choose from. In this blog post, I will show you how to use the AWS REST APIs to secure S3 objects using KMS keys via SSE. Using the native REST APIs vs. the AWS SDKs may be a better option for you if you are looking to develop cross-platform code or want more control over API usage within your applications. (more…)
Seamlesssly joining Windows EC2 instances in AWS to a Microsoft Active Directory domain is a common scenario, especially for enterprises building a hybrid cloud architecture. With AWS Directory Service, you can target an Active Directory domain managed on-premises or within AWS. How to Connect Your On-Premises Active Directory to AWS Using AD Connector takes you through the process of implementing that scenario.
In this blog post, I will first show you how to get the Amazon EC2 launch wizard to pick up your custom domain-join configuration by default—including an organizational unit—when launching new Windows instances. I also will show you how to enable an EC2 Auto Scaling group to automatically join newly launched instances to a target domain. The Amazon EC2 Simple Systems Manager (SSM) plays a central role in enabling both scenarios. (more…)
Developers can now programmatically create and configure Simple AD and AD Connector directories in AWS Directory Service via the AWS SDKs or CLI. You can also now use Cloud Trail to log API actions performed via an SDK, the CLI, or AWS Directory Service console. Permissions for performing these actions can be controlled via an AWS IAM policy, and the APIs can be used in all AWS regions in which Directory Service is available.
If you have questions, please post them on the Directory Service forum.
Last month, the AWS Security Blog encouraged you to adhere to AWS Identity and Access Management (IAM) best practices. One of these best practices is to lock away your AWS account (root) access keys and password, and not use them for day-to-day interaction with AWS. In fact, when it comes to your root account access keys, we recommend that you delete them. How, though, do you determine if your root account even has access keys?
In the past, the easiest way to determine if your root account had access keys was to sign in to the AWS Management Console using your root account password, which is something we recommend against doing regularly. Instead, you should enable multi-factor authentication (MFA) on your root account, and then you should only sign in with your root account when absolutely necessary. Furthermore, if you wanted to determine programmatically whether your root account had an access key, the only way to do it was to use the root account access key, which is an obvious dilemma. Now, though, it’s possible by using the AWS Command Line Interface (CLI) or the AWS SDKs to use the credentials of an IAM user to determine whether your root account has access keys. For the rest of this post, I’ll show you how you can use the AWS CLI to check if your root account has access keys. (more…)
Changing access keys (which consist of an access key ID and a secret access key) on a regular schedule is a well-known security best practice because it shortens the period an access key is active and therefore reduces the business impact if they are compromised. Having an established process that is run regularly also ensures the operational steps around key rotation are verified, so changing a key is never a scary step.
In an earlier post, we described Identity and Access Management (IAM) roles for Amazon EC2. If you run applications on EC2 that need access to AWS services, we strongly recommend using this feature. Roles use temporary security credentials that auto-expire and auto-renew, so you don’t have to worry about access key rotation – AWS does it for you. However, if you are running applications somewhere other than on EC2, you should add access key rotation to your application management process. In this post, Cristian Ilac, software development manager on the IAM team, will walk you through the steps to rotate access keys for an IAM user. (more…)