Create an IAM user for workloads that can't use
IAM roles
As a best practice, we recommend that you
require your human users to use temporary credentials when accessing AWS. You can use an
identity provider for your human users to provide federated access to AWS accounts by
assuming roles, which provide temporary credentials. For centralized access management, we
recommend that you use AWS IAM Identity Center
(IAM Identity Center) to manage access to your accounts and permissions within those accounts. You
can create and manage your user identities, including your administrative user, with IAM Identity Center. If
you are using an external identity provider, you can also configure the access permissions for
user identities in IAM Identity Center. For more information, see What is AWS IAM Identity Center in the
AWS IAM Identity Center User Guide.
If your use case requires IAM users with programmatic access and long-term credentials, we
recommend that you establish procedures to update access keys when needed. For more information,
see Update access keys.
To perform some account and service management tasks, you must sign in using root user
credentials. To view the tasks that require you to sign in as the root user, see Tasks that require root user credentials.
To create an IAM user for workloads that can't use IAM roles
Choose the tab for the method you want to follow to create the IAM user for a
workload:
To perform the following steps, you must have at least the following IAM permissions:
-
iam:AddUserToGroup
-
iam:AttachGroupPolicy
-
iam:CreateAccessKey
-
iam:CreateGroup
-
iam:CreateServiceSpecificCredential
-
iam:CreateUser
-
iam:GetAccessKeyLastUsed
-
iam:GetAccountPasswordPolicy
-
iam:GetAccountSummary
-
iam:GetGroup
-
iam:GetLoginProfile
-
iam:GetPolicy
-
iam:GetRole
-
iam:GetUser
-
iam:ListAccessKeys
-
iam:ListAttachedGroupPolicies
-
iam:ListAttachedUserPolicies
-
iam:ListGroupPolicies
-
iam:ListGroups
-
iam:ListGroupsForUser
-
iam:ListInstanceProfilesForRole
-
iam:ListMFADevices
-
iam:ListPolicies
-
iam:ListRoles
-
iam:ListRoleTags
-
iam:ListSSHPublicKeys
-
iam:ListServiceSpecificCredentials
-
iam:ListSigningCertificates
-
iam:ListUserPolicies
-
iam:ListUserTags
-
iam:ListUsers
-
iam:UploadSSHPublicKey
-
iam:UploadSigningCertificate
- IAM console
-
-
Follow the sign-in procedure appropriate to your user type as described in the topic How to sign in to AWS in the AWS Sign-In User
Guide.
-
On the Console Home page, select the IAM service.
-
In the navigation pane, choose Users and then choose
Create users.
-
On the Specify user details page, do the following:
-
For User name, type WorkloadName
. Replace WorkloadName
with the name of
the workload that will be using the account.
-
Choose Next.
-
(Optional) On the Set Permissions page, do the
following:
-
Choose Add user to group.
-
Choose Create group.
-
In the Create user group dialog box, for User
group name type a name that represents the use of the workloads in
the group. For this example, use the name
Automation
.
-
Under Permissions policies select the checkbox for the
PowerUserAccess managed policy.
Enter Power into the Permissions
policies search box to quickly find the managed policy.
-
Choose Create user group.
-
Back on the page with the list of IAM groups, select the checkbox for your
new user group. Choose Refresh if you don't see the new
user group in the list.
-
Choose Next.
-
(Optional) In the Tags section, add metadata to the user by
attaching tags as key-value pairs. For more information, see Tags for AWS Identity and Access Management resources.
-
Verify the user group memberships for the new user. When you are ready to
proceed, choose Create user.
-
A status notification appears informing you that the user was created
successfully. Select View user to go to the user details
page
-
Select the Security credentials tab. Then create the
credentials needed for the workload.
-
Access keys–Select Create access
key to generate and download access keys for the user.
This is your only opportunity to view or download the secret access keys, and you must
provide this information to your users before they can use the AWS API. Save the user's
new access key ID and secret access key in a safe and secure place. You
will not have access to the secret keys again after this step.
-
SSH public keys for AWS CodeCommit–Select
Upload SSH public key to upload an SSH public key so that
the user can communicate with CodeCommit repositories over SSH.
-
HTTPS Git credentials for AWS CodeCommit–Select
Generate credentials to generate a unique set of user
credentials to use with Git repositories. Select Download
credentials to save the user name and password to a .csv file. This
is the only time that information is available. If you forget or lose the
password you will need to reset it.
-
Credentials for Amazon Keyspaces (for Apache Cassandra)–Select
Generate credentials to generate a service-specific user
credentials to use with Amazon Keyspaces. Select Download credentials
to save the user name and password to a .csv file. This is the only time that
information is available. If you forget or lose the password you will need to
reset it.
-
X.509 Signing certificates–Select
Create X.509 Certificate if you need to make secure
SOAP-protocol requests and are in a Region that's not supported by AWS Certificate Manager.
ACM is the preferred tool to provision, manage, and deploy your server
certificates. For more information about using ACM, see the AWS Certificate Manager User Guide.
You have created a user with programmatic access and configured it with the
PowerUserAccess job function. This user's permissions policy
grants full access to every service except for IAM and AWS Organizations.
You can use this same process to give additional workloads programmatic access to
your AWS account resources, if the workloads are unable to assume IAM roles. This
procedure used the PowerUserAccess managed policy to assign
permissions. To follow the best practice of least privilege, consider using a more
restrictive policy or creating a custom policy that restricts access to only resources
required by the program. To learn about using policies that restrict user permissions to
specific AWS resources, see Access management for AWS resources and Example IAM identity-based policies. To add
additional users to the user group after it's created, see Edit users in IAM IAM groups.
- AWS CLI
-
-
Create a user named Automation
.
aws iam create-user \
--user-name Automation
-
Create an IAM user group named AutomationGroup
, attach
the AWS managed policy PowerUserAccess
to the group, and then add the
Automation
user to the group.
An AWS managed policy is a standalone policy that is
created and administered by AWS. Each policy has its own Amazon Resource Name
(ARN) that includes the policy name. For example,
arn:aws:iam::aws:policy/IAMReadOnlyAccess
is an AWS managed
policy. For more information about ARNs, see IAM ARNs. For a list of AWS managed policies for
AWS services, see AWS managed
policies.
-
aws iam create-group
aws iam create-group \
--group-name AutomationGroup
-
aws iam
attach-group-policy
aws iam attach-group-policy \
--policy-arn arn:aws:iam::aws:policy/PowerUserAccess \
--group-name AutomationGroup
-
aws iam
add-user-to-group
aws iam add-user-to-group \
--user-name Automation
\
--group-name AutomationGroup
-
Run the aws iam
get-group command to list the AutomationGroup
and its members.
aws iam get-group \
--group-name AutomationGroup
-
Create the security credentials needed for the workload.
-
Create access keys for testing–aws iam
create-access-key
aws iam create-access-key \
--user-name Automation
The output of this command displays the secret access key and the access key
ID. Record and store this information in a secure location. If these credentials
are lost, they can't be recovered, and you must create a new access key.
These IAM user access keys are long-term credentials that present a
security-risk to your account. After you have completed testing, we recommend
that you delete these access keys. If you have scenarios in which you are
considering access keys, investigate whether you can enable MFA for your
workload IAM user and use aws sts
get-session-token to obtain temporary credentials for the session
instead of using IAM access keys.
-
Upload SSH public keys for AWS CodeCommit–aws iam
upload-ssh-public-key
The following example assumes that you have your SSH public keys stored in
the file sshkey.pub
.
aws upload-ssh-public-key \
--user-name Automation
\
--ssh-public-key-body file://sshkey.pub
-
Upload an X.509 signing certificate–aws iam
upload-signing-certificate
Upload an X.509 certificate if you need to make secure SOAP-protocol
requests and are in a Region that's not supported by AWS Certificate Manager. ACM is the
preferred tool to provision, manage, and deploy your server certificates. For
more information about using ACM, see the AWS Certificate Manager User Guide.
The following example assumes that you have your X.509 signing certificate
stored in the file certificate.pem
.
aws iam upload-signing-certificate \
--user-name Automation \
--certificate-body file://certificate.pem
You can use this same process to give additional workloads programmatic access to
your AWS account resources, if the workloads are unable to assume IAM roles. This
procedure used the PowerUserAccess managed policy to assign
permissions. To follow the best practice of least privilege, consider using a more
restrictive policy or creating a custom policy that restricts access to only resources
required by the program. To learn about using policies that restrict user permissions to
specific AWS resources, see Access management for AWS resources and Example IAM identity-based policies. To add
additional users to the user group after it's created, see Edit users in IAM IAM groups.