Jump to content

Search the Community

Showing results for tags 'iam roles'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

There are no results to display.

There are no results to display.


Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Website URL


LinkedIn Profile URL


About Me


Cloud Platforms


Cloud Experience


Development Experience


Current Role


Skills


Certifications


Favourite Tools


Interests

Found 8 results

  1. You can now use AWS Identity and Access Management (IAM) Roles Anywhere to obtain temporary security credentials for workloads that run outside of AWS that are valid for up to 12 hours. You can use those temporary security credentials to sign and authenticate any AWS request. Previously, the temporary security credentials vended by IAM Roles Anywhere were valid for up to 1 hour. Now, you have the ability to optimize the number of CreateSession requests made to IAM Roles Anywhere by extending the credentials validity for a longer duration to meet your business needs. The duration can range from 15 minutes to 12 hours, with a default value of 1 hour. View the full article
  2. Today, AWS Identity and Access Management (IAM) Roles Anywhere released credential helper version 1.1.0 to include support for X.509 certificates and private keys that are stored in Public-Key Cryptography Standards (PKCS) #11 compatible security modules. IAM Roles Anywhere credential helper is a tool that manages the process of signing CreateSession API with the private key associated with an X.509 end-entity certificate and calls the endpoint to obtain temporary AWS credentials. With this release, you can use the credential helper to delegate signing operations to keys stored within PKCS #11 compatible security modules, without those keys ever leaving those stores; which can help improve your security posture. View the full article
  3. You can now use Credential Control Properties to more easily restrict the usage of your IAM Roles for EC2. View the full article
  4. We are excited to launch two new features that help enforce access controls with Amazon EMR on EC2 clusters (EMR Clusters). These features are supported with jobs that are submitted to the cluster using the EMR Steps API. First is Runtime Role with EMR Steps. A Runtime Role is an AWS Identity and Access Management (IAM) role that you associate with an EMR Step. An EMR Step uses this role to access AWS resources. The second is integration with AWS Lake Formation to apply table and column-level access controls for Apache Spark and Apache Hive jobs with EMR Steps. View the full article
  5. AWS Identity and Access Management (IAM) now enables workloads that run outside of AWS to access AWS resources using IAM Roles Anywhere. IAM Roles Anywhere allows your workloads such as servers, containers, and applications to use X.509 digital certificates to obtain temporary AWS credentials and use the same IAM roles and policies that you have configured for your AWS workloads to access AWS resources. View the full article
  6. IAM helps customers with capabilities to analyze access and achieve least privilege. When you are working on new permissions for your teams, you can use IAM Access Analyzer policy generation to create a policy based on your access activity and set fine-grained permissions. To analyze and refine existing permissions, you can use last accessed information to identify unused actions in your IAM policies and reduce access. When we launched action last accessed in 2020, we started with S3 management actions to help you restrict access to your critical business data. Now, IAM is increasing visibility into access history by extending last accessed information to Amazon EC2, AWS IAM, and AWS Lambda actions. This makes it easier for you to analyze access and reduce EC2, IAM, and Lambda permissions by providing the latest timestamp when an IAM user or role used an action. Using last accessed information, you can identify unused actions in your IAM policies and tighten permissions confidently. View the full article
  7. AWS Amplify CLI now supports IAM permission boundaries to limit Amplify-generated IAM roles. The AWS Amplify CLI is a command line toolchain that helps frontend developers create app backends in the cloud that include IAM roles controlling access to AWS resources. With IAM permissions boundaries, Amplify-generated IAM roles can perform only the actions that are allowed by both the roles’ policies and permissions boundary. View the full article
  8. You can configure the AWS CLI to assume an IAM role for you in combination with MFA. If you are a power user of the CLI, you will realize that you have to enter your MFA token every 60 minutes, which is annoying. /images/2019/08/timeout.jpg You will learn how to fix that in the following. AWS account setup Let’s assume we have three AWS accounts. Account id Alias Description 000000000000 iam Only IAM users are created in this account 111111111111 dev Development workloads 222222222222 prod Production workloads Besides that: In the iam account, an IAM user named michael is created. MFA is enabled, and an access key is generated. In the dev and prod accounts, the following IAM role is created (CloudFormation template): --- AWSTemplateFormatVersion: '2010-09-09' Resources: AdminRole: Type: 'AWS::IAM::Role' Properties: AssumeRolePolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Principal: AWS: 'arn:aws:iam::000000000000:root' # replace this with your iam account id Action: 'sts:AssumeRole' Condition: Bool: 'aws:MultiFactorAuthPresent': true ManagedPolicyArns: - 'arn:aws:iam::aws:policy/AdministratorAccess' MaxSessionDuration: 43200 # 12 hours in seconds RoleName: Admin Ensure that you set the MaxSessionDuration property! The default is 60 minutes. Configuring the AWS CLI The AWS CLI stores the configuration in ~/.aws/credentials (or %UserProfile%\.aws\credentials if you are using Windows). First of all, configure the access key from the michael IAM user using the aws_access_key_id and aws_secret_access_key configuration values. The value between the square brackets is called the profile name. [iam] aws_access_key_id = AKIA**************** aws_secret_access_key = **************************************** After that, configure the IAM roles you want to assume. The following configuration values are used: Configuration value Description role_arn ARN of the role you want to assume source_profile Reference the profile of the IAM user mfa_serial ARN of the virtual MFA device or the serial number for a hardware device duration_seconds The expiry of the credentials returned by the assume role call Ensure that you set the duration_seconds property! The default is 60 minutes. Add the following profiles to the credentials file. [dev] role_arn = arn:aws:iam::111111111111:role/Admin source_profile = iam mfa_serial = arn:aws:iam::000000000000:mfa/michael duration_seconds = 43200 [prod] role_arn = arn:aws:iam::222222222222:role/Admin source_profile = iam mfa_serial = arn:aws:iam::000000000000:mfa/michael duration_seconds = 43200 Using the profiles The --profile parameter lets you specify the profile you want to use when working with the CLI. aws --profile dev s3 ls aws --profile prod s3 ls The AWS CLI will ask you for your MFA token the first time you make a call. You can also set the AWS_PROFILE environment variable to avoid typing --profile ... all the time. export AWS_PROFILE=dev aws s3 ls Summary To avoid frequent re-enter of the MFA token when using the AWS CLI, you have to adjust the MaxSessionDuration of the IAM role and the duration_seconds configuration value of the AWS CLI. View the full article
  • Forum Statistics

    63.7k
    Total Topics
    61.7k
    Total Posts
×
×
  • Create New...