> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Controlling Access to Bedrock Using IAM Part 1
> Using AWS IAM to enforce least privilege for Amazon Bedrock, restricting which foundation models, knowledge bases, and guardrails principals can access with example allow and explicit deny policies
In this lesson we show how to control access to Amazon Bedrock using AWS Identity and Access Management (IAM). You’ll learn how to decide who can use Bedrock, which foundation models they can call, and how to restrict access to guardrails and knowledge bases used for retrieval-augmented generation (RAG).
This lesson covers the problem of unrestricted Bedrock access, the IAM-based solution, example policies (comprehensive and minimal), how those policies behave when attached to principals, and the recommended next steps.
## Problem: Unrestricted Bedrock Access Creates Security and Governance Risks
Different users and applications will have different Bedrock needs. Typical Bedrock resources include foundation models, knowledge bases, and guardrails. Granting broad Bedrock permissions without constraints can lead to multiple risks:
* Uncontrolled invocation of any model, including costly or sensitive models.
* Access to private or sensitive knowledge bases used for RAG.
* The ability to bypass guardrails if their use is not enforced.
* Inconsistent or unsafe usage patterns across your organization.
A lack of fine-grained controls introduces both security and governance problems that IAM can help mitigate.
## Solution: Use IAM to Apply Least Privilege for Bedrock
IAM is the recommended mechanism to:
* Define who can call Bedrock APIs.
* Restrict which foundation models can be invoked.
* Limit RAG operations to specific knowledge bases.
* Enforce guardrail usage and prevent modification of approved guardrails.
* Apply the principle of least privilege so each principal gets only the permissions it needs.
Below are example policies and explanations showing how to tighten Bedrock access.
## Example IAM policy (comprehensive)
This policy demonstrates common controls:
* Allow a single foundation model.
* Explicitly deny all other models.
* Allow RAG operations on a specific knowledge base.
* Allow applying one approved guardrail while denying any guardrail create/update/delete actions.
```json theme={null}
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowSpecificFoundationModel",
"Effect": "Allow",
"Action": [
"bedrock:InvokeModel"
],
"Resource": [
"arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-3-sonnet"
]
},
{
"Sid": "DenyAllOtherModels",
"Effect": "Deny",
"Action": [
"bedrock:InvokeModel"
],
"NotResource": [
"arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-3-sonnet"
]
},
{
"Sid": "AllowSpecificKnowledgeBase",
"Effect": "Allow",
"Action": [
"bedrock:Retrieve",
"bedrock:RetrieveAndGenerate"
],
"Resource": [
"arn:aws:bedrock:us-east-1:123456789012:knowledge-base/kb-abc123"
]
},
{
"Sid": "AllowSpecificGuardrail",
"Effect": "Allow",
"Action": [
"bedrock:ApplyGuardrail"
],
"Resource": [
"arn:aws:bedrock:us-east-1:123456789012:guardrail/gr-xyz789"
]
},
{
"Sid": "DenyGuardrailModification",
"Effect": "Deny",
"Action": [
"bedrock:CreateGuardrail",
"bedrock:UpdateGuardrail",
"bedrock:DeleteGuardrail"
],
"Resource": "*"
}
]
}
```
Key takeaways from this example:
* The `AllowSpecificFoundationModel` statement grants `bedrock:InvokeModel` only for the specified Claude 3 Sonnet model.
* The `DenyAllOtherModels` statement uses `NotResource` and an explicit `Deny` to prevent invocation of any other model — an explicit `Deny` always overrides `Allow`.
* `AllowSpecificKnowledgeBase` limits RAG operations (`bedrock:Retrieve`, `bedrock:RetrieveAndGenerate`) to a single knowledge base.
* Combining `AllowSpecificGuardrail` with `DenyGuardrailModification` permits the application of a tested guardrail but prevents creating, editing, or deleting guardrails.
Always prefer narrowly scoped policies (by action and by resource) and use explicit Deny statements when you need to make sure a capability cannot be used.
## Minimal IAM policy (focused example)
A smaller, focused policy that covers two common needs: allowing one model and permitting RAG against one knowledge base.
```json theme={null}
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowModelUsage",
"Effect": "Allow",
"Action": [
"bedrock:InvokeModel"
],
"Resource": [
"arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-3-sonnet"
]
},
{
"Sid": "AllowKnowledgeBaseRAG",
"Effect": "Allow",
"Action": [
"bedrock:RetrieveAndGenerate"
],
"Resource": [
"arn:aws:bedrock:us-east-1:123456789012:knowledge-base/kb-abc123"
]
}
]
}
```
## IAM concepts for Bedrock — quick reference
* A policy `Statement` can `Allow` or `Deny` one or more actions and can be scoped with `Resource` or `NotResource`.
* Use `bedrock:InvokeModel` to grant or prevent generation from foundation models.
* Use `bedrock:Retrieve` and `bedrock:RetrieveAndGenerate` to control knowledge-base retrieval and RAG operations.
* Use `bedrock:ApplyGuardrail` to allow applying an approved guardrail; use `bedrock:CreateGuardrail`, `bedrock:UpdateGuardrail`, and `bedrock:DeleteGuardrail` to control guardrail lifecycle.
* An explicit `Deny` always overrides `Allow`. Use `Deny` to enforce strict prohibitions.
## Mapping common SDK calls to IAM actions
When using an AWS SDK, high-level methods map to Bedrock IAM actions. Test policies by attaching them to a representative principal (role or user) and validating allowed and denied behaviors.
| SDK / API call examples | Corresponding IAM action |
| - | - |
| `InvokeModel` (SDK) | `bedrock:InvokeModel` |
| `Converse` (SDK) | `bedrock:InvokeModel` |
| RAG retrieval functions | `bedrock:Retrieve` |
| RAG generate functions | `bedrock:RetrieveAndGenerate` |
| Apply guardrail | `bedrock:ApplyGuardrail` |
Note: Both `InvokeModel` and `Converse` map to the same underlying IAM action (`bedrock:InvokeModel`). Controlling `bedrock:InvokeModel` in a policy will affect both SDK methods.
## Recommended testing and next steps
* Attach example policies to test roles and users in a sandbox account.
* Verify allowed operations succeed and that explicit Deny statements prevent the prohibited actions.
* For stricter enforcement, combine resource-level restrictions with IAM policy conditions (future content will cover forcing guardrail usage via request attributes and additional policy condition examples).
* Document which principals require access to which foundation models and knowledge bases — then codify those requirements into least-privilege IAM policies.
## Links and references
* [AWS SDK for Python (Boto3)](https://aws.amazon.com/sdk-for-python/)
* [AWS IAM User Guide](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)
* [Amazon Bedrock documentation](https://docs.aws.amazon.com/bedrock)
Next lesson: policy conditions and enforcement patterns — how to require the use of a specific guardrail or disallow certain model parameters via IAM conditions.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.