How Amazon Lex Works with IAM

Before you use AWS Identity and Access Management (IAM) to manage access to Amazon Lex, you should understand which IAM features are available to use with Amazon Lex. For a high-level view of how Amazon Lex and other AWS services work with IAM, see AWS Services That Work with IAM in the IAM User Guide.

Amazon Lex Identity-Based Policies

To specify allowed or denied actions and resources and the conditions under which actions are allowed or denied, use IAM identity-based policies,. Amazon Lex supports specific actions, resources, and condition keys. To learn about all of the elements that you use in a JSON policy, see IAM JSON Policy Elements Reference in the IAM User Guide.

Actions

The Action element of an IAM identity-based policy describes the specific action or actions that will be allowed or denied by the policy. Policy actions usually have the same name as the associated AWS API operation. The action is used in a policy to grant permissions to perform the associated operation.

In Amazon Lex, policy actions use the following prefix before the action: lex:. For example, to grant someone permission to call an Amazon Lex bot with the PostContent operation, you include the lex:PostContent action in their policy. Policy statements must include either an Action or NotAction element. Amazon Lex defines actions that describe the tasks that you can perform with this service. To see a list of Amazon Lex actions, see Actions Defined by Amazon Lex in the IAM User Guide.

To specify multiple actions in a single statement, separate them with commas as follows.

"Action": [
      "lex:action1",
      "lex:action2"

You can specify multiple actions using wildcards (*). For example, to specify all actions that begin with the word Put, include the following action.

"Action": "lex:Put*"

Resources

The Resource element specifies the object or objects to which the action applies. Statements must include either a Resource or a NotResource element. You specify a resource using an ARN or, to indicate that the statement applies to all resources, the wildcard (*).

An Amazon Lex bot resource ARN has the following format.

arn:aws:lex:${Region}:${Account}:bot:${Bot-Name}

For more information about the format of ARNs, see Amazon Resource Names (ARNs) and AWS Service Namespaces.

For example, to specify the OrderFlowers bot in your statement, use the following ARN.

"Resource": "arn:aws:lex:us-east-2:123456789012:bot:OrderFlowers"

To specify all bots that belong to a specific account, use the wildcard (*).

"Resource": "arn:aws:lex:us-east-2:123456789012:bot:*"

Some Amazon Lex actions, such as those for creating resources, can't be performed on a specific resource. In those cases, you must use the wildcard, (*).

"Resource": "*"

For a list of Amazon Lex resource types and their ARNs, see Resources Defined by Amazon Lex in the IAM User Guide. To learn with which actions you can specify the ARN of each resource, see Actions Defined by Amazon Lex.

Condition Keys

Use the Condition element (or a Condition block) to specify conditions in which a statement is in effect. The Condition element is optional. You can build conditional expressions that use condition operators, such as equals or less than, to match the condition in the policy with values in the request.

If you specify multiple Condition elements in a statement, or multiple keys in a single Condition element, AWS evaluates them using a logical AND operation. If you specify multiple values for a single condition key, AWS evaluates the condition using a logical OR operation. All of the conditions must be met before the statement's permissions are granted.

You can also use placeholder variables when you specify conditions. For example, you can grant an IAM user permission to access a resource only if it is tagged with their IAM user name. For more information, see IAM Policy Elements: Variables and Tags in the IAM User Guide.

Amazon Lex defines its own set of condition keys and also supports using some global condition keys. For a list of all AWS global condition keys, see AWS Global Condition Context Keys in the IAM User Guide.

The following table lists the Amazon Lex condition keys that apply to Amazon Lex resources. You can include these keys in Condition elements in an IAM permissions policy.

Amazon Lex Condition Key	Description	Value Type	Permission
lex:associatedIntents	Scopes the set of intents that can be used when creating or modifying the definition of a bot.	Array of strings	lex:PutBot
lex:associatedSlotTypes	Scopes the set of slot types that can be used when creating or modifying the definition of a slot type.	Array of strings	lex:PutIntent
lex:ChannelType	Scopes the type of bot channel association that a user can create, get, or delete.	String	lex:CreateBotChannelAssociation lex:DeleteBotChannelAssociation lex:GetBotChannelAssociation

Examples

For examples of Amazon Lex identity-based policies, see Amazon Lex Identity-Based Policy Examples.

Amazon Lex Resource-Based Policies

Resource-based policies are JSON policy documents that specify what actions a specified principal can perform on the Amazon Lex resource and under what conditions. Amazon Lex supports resource-based permissions policies for bots, intents, and slot types. Use resource-based policies to grant usage permission to other accounts on a per-resource basis. You can also use a resource-based policy to allow an AWS service to access your Amazon Lex resources.

To enable cross-account access, you can specify an entire account or you can specify IAM entities in another account as the principal in a resource-based policy. Adding a cross-account principal to a resource-based policy is only the first step in establishing the trust relationship. When the principal and the resource are in different AWS accounts, you must also grant the principal entity permission to access the resource. Grant permission by attaching an identity-based policy to the entity. However, if a resource-based policy grants access to a principal in the same account, no additional identity-based policy is required. For more information, see How IAM Roles Differ from Resource-based Policies in the IAM User Guide.

Examples

For examples of Amazon Lex resource-based policies, see Amazon Lex Resource-Based Policy Example,

Authorization Based on Amazon Lex Tags

You can associate tags with certain types of Amazon Lex resources for authorization. To control access based on tags, provide tag information in the condition element of a policy by using the lex:ResourceTag/${TagKey}, aws:RequestTag/${TagKey}, or aws:TagKeys condition keys.

For information about tagging Amazon Lex resources, see Tagging Your Amazon Lex Resources. For an example identity-based policy that limits access to a resource based on the resource tags, see Example: Use a Tag to Access a Resource. For more information about using tags to limit access to resources, see Controlling Access Using Tags in the IAM User Guide.

The following table lists the actions and corresponding resource types for tag-based access control. Each action is authorized based on the tags associated with the corresponding resource type.

Action	Resource type	Condition keys	Notes
CreateBotVersion	bot	lex:ResourceTag
DeleteBot	bot	lex:ResourceTag
DeleteBotAlias	alias	lex:ResourceTag
DeleteBotChannelAssociation	channel	lex:ResourceTag
DeleteBotVersion	bot	lex:ResourceTag
DeleteSession	bot or alias	lex:ResourceTag	Uses tags associated with the bot when alias is set to $LATEST. Uses tags associated with the specified alias when used with other aliases.
DeleteUtterances	bot	lex:ResourceTag
GetBot	bot or alias	lex:ResourceTag	Uses tags associated with the bot when versionOrAlias is set to $LATEST or numeric version. Uses tags associated with the specified alias when used with aliases
GetBotAlias	alias	lex:ResourceTag
GetBotChannelAssociation	chanel	lex:ResourceTag
GetBotChannelAssociations	chanel	lex:ResourceTag	Uses tags associated with the bot when alias is set to "-". Uses tags associated with the specified alias when a bot alias is specified
GetBotVersions	bot	lex:ResourceTag
GetExport	bot	lex:ResourceTag
GetSession	bot or alias	lex:ResourceTag	Uses tags associated with the bot when alias is set to $LATEST. Uses tags associated with the specified alias when used with other aliases.
GetUtterancesView	bot	lex:ResourceTag
ListTagsForResource	bot, alias, or channel	lex:ResourceTag
PostContent	bot or alias	lex:ResourceTag	Uses tags associated with the bot when alias is set to $LATEST. Uses tags associated with the specified alias when used with other aliases.
PostText	bot or alias	lex:ResourceTag	Uses tags associated with the bot when alias is set to $LATEST. Uses tags associated with the specified alias when used with other aliases.
PutBot	bot	lex:ResourceTag, aws:RequestTag, aws:TagKeys
PutBotAlias	alias	lex:ResourceTag, aws:RequestTag, aws:TagKeys
PutSession	bot or alias	lex:ResourceTag	Uses tags associated with the bot when alias is set to $LATEST. Uses tags associated with the specified alias when used with other aliases.
StartImport	bot	lex:ResourceTag	Relies on access policy for the PutBot operation. Tags and permissions specific to the StartImport operation are ignored.
TagResource	bot, alias, or channel	lex:ResourceTag, aws:RequestTag, aws:TagKeys
UntagResource	bot, alias, or channel	lex:ResourceTag, aws:RequestTag, aws:TagKeys

Amazon Lex IAM Roles

An IAM role is an entity within your AWS account that has specific permissions.

Using Temporary Credentials with Amazon Lex

You can use temporary credentials to sign in with federation, assume an IAM role, or to assume a cross-account role. You obtain temporary security credentials by calling AWS STS API operations such as AssumeRole or GetFederationToken.

Amazon Lex supports using temporary credentials.

Service-Linked Roles

Service-linked roles allow AWS services to access resources in other services to complete an action on your behalf. Service-linked roles appear in your IAM account and are owned by the service. An IAM administrator can view, but not edit, the permissions for service-linked roles.

Amazon Lex supports service-linked roles. For details about creating or managing Amazon Lex service-linked roles, see Step 1: Create a Service-Linked Role (AWS CLI).

Service Roles

A service can assume a service role on your behalf. This role allows the service to access resources in other services to complete an action on your behalf. Service roles appear in your IAM account and are owned by the account. This means that an IAM administrator can change the permissions for this role. However, doing so might prevent the service from functioning as expected.

Amazon Lex supports service roles.

Choosing an IAM Role in Amazon Lex

Amazon Lex uses service-linked roles to call Amazon Comprehend and Amazon Polly. It uses resource-level permissions on your AWS Lambda functions to invoke them.

You must provide an IAM role to enable conversation tagging. For more information, see Creating an IAM Role and Policies for Conversation Logs.