Terms and concepts for AWS RAM

The following concepts help explain how you can use AWS Resource Access Manager (AWS RAM) to share your resources.

Resource share

You share resources using AWS RAM by creating a resource share. A resource share has the following three elements:

After you use AWS RAM to create a resource share, the principals specified in the resource share can be granted access to the share's resources.

Sharing account

The sharing account contains the resource that is shared and in which the AWS RAM administrator creates the AWS resource share by using AWS RAM.

An AWS RAM administrator is an IAM principal who has permissions to create and configure resource shares in the AWS account. Because AWS RAM works by attaching a resource-based policy to the resources in a resource share, the AWS RAM administrator also must have permissions to call the PutResourcePolicy operation in the AWS service for each resource type included in a resource share.

Consuming principals

The consuming account is the AWS account to which a resource is shared. The resource share can specify an entire account as the principal, or for some resource types, individual roles or users in the account. For information about which resource types support this type of sharing, see Shareable AWS resources and view the Can share with IAM roles & users column.

AWS RAM also supports service principals as consumers of resource shares. For information about which resource types support this type of sharing, see Shareable AWS resources and view the Can share with service principals column.

The principals in the consuming account can perform only those actions allowed by both of the following permissions:

AWS RAM supports the following IAM principal types as consumers of resource shares:

Resource-based policy

Resource-based policies are JSON text documents that implement the IAM policy language. Unlike identity-based policies that you attach to the principal, such as an IAM role or user, you attach resource-based policies to the resource. AWS RAM authors resource-based policies on your behalf based on the information you provide for your resource share. You must specify a Principal policy element that determines who can access the resource. For more information, see Identity-based policies and resource-based policies in the IAM User Guide.

The resource-based policies generated by AWS RAM are evaluated along with all other IAM policy types. This includes any IAM identity-based policies attached to the principals who are attempting to access the resource, and service control policies (SCPs) for AWS Organizations that might apply to the AWS account. Resource-based policies generated by AWS RAM participate in the same policy evaluation logic as all other IAM policies. For complete details of policy evaluation and how to determine the resulting permissions, see Policy evaluation logic in the IAM User Guide.

AWS RAM provides a simple and secure resource sharing experience by providing easy-to-use abstraction resource-based policies.

For those resource types that support resource-based policies, AWS RAM automatically constructs and manages the resource-based policies for you. For a given resource, AWS RAM builds the resource-based policy by combining the information from all of the resource shares that include that resource. For example, consider an Amazon SageMaker AI pipeline that you share by using AWS RAM and include in two different resource shares. You could use one resource share to provide read-only access to your entire organization. You could then use the other resource share to grant only SageMaker AI execution permissions to a single account. AWS RAM automatically combines those two different sets of permissions into a single resource policy with multiple statements. It then attaches the combined resource-based policy to the pipeline resource. You can view this underlying resource policy by calling the GetResourcePolicy operation. AWS services then use that resource-based policy to authorize any principal who attempts to perform an action on the shared resource.

Although you can manually create the resource-based policies and attach them to your resources by calling PutResourcePolicy, we recommend that you use AWS RAM because it provides the following advantages:

By using AWS RAM, you can even share some resource types that don’t support resource-based policies yet. For such resource types, AWS RAM automatically generates a resource-based policy as a representation of the actual permissions. Users can view this representation by calling GetResourcePolicy. This includes the following resource types:

Examples of AWS RAM generated resource-based policies

If you share an EC2 Image Builder image resource with an individual account, AWS RAM generates a policy that looks like the following example and attaches it to any image resources that are included in the resource share.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {"AWS": "arn:aws:iam::123456789012:root"},
            "Action": [
                "imagebuilder:GetImage",
                "imagebuilder:ListImages",
            ],
            "Resource": "arn:aws:imagebuilder:us-east-1:123456789012:image/testimage/1.0.0/44"
        }
    ]
}

If you share an EC2 Image Builder image resource with an IAM role or user in a different AWS account, AWS RAM generates a policy that looks like the following example and attaches it to any image resources that are included in the resource share.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/MySampleRole"
      },
      "Action": [
          "imagebuilder:GetImage",
          "imagebuilder:ListImages",
      ],
      "Resource": "arn:aws:imagebuilder:us-east-1:123456789012:image/testimage/1.0.0/44"
    }
  ]
}

If you share an EC2 Image Builder image resource with all of the accounts in an organization or with the accounts an OU, AWS RAM generates a policy that looks like the following example and attaches it to any image resources that are included in the resource share.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": [
                "imagebuilder:GetImage",
                "imagebuilder:ListImages",
            ],
            "Resource": "arn:aws:imagebuilder:us-east-1:123456789012:image/testimage/1.0.0/44"
            "Condition": {
                "StringEquals": {
                    "aws:PrincipalOrgID": "o-123456789"
                }
            }
        }
    ]
}

Implications of using "Principal": "*" in a resource-based policy

When you include "Principal": "*" in a resource-based policy, the policy grants access to all IAM principals in the account that contains the resource, subject to any restrictions imposed by a Condition element, if it exists. Explicit Deny statements in any policy that applies to the calling principal overrides the permissions granted by this policy. However, an implicit Deny (meaning the lack of an explicit Allow) in any applicable identity policies, permissions boundary policies, or session policies does not result in a Deny to the principals granted access to an action by such a resource-based policy.

If this behavior isn’t desirable for your scenario, then you can limit this behavior by adding an explicit Deny statement to an identity policy, permissions boundary, or session policy that affects the relevant roles and users.

Managed permissions

Managed permissions define what actions principals can perform under which conditions on supported resource types in a resource share. When you create a resource share, you must specify which managed permission to use for each resource type included in the resource share. A managed permission lists the set of actions and conditions that principals can perform with the resource shared using AWS RAM.

You can attach only one managed permission for each resource type in a resource share. You can't create a resource share in which some resources of a certain type use one managed permission and other resources of the same type use a different managed permission. To do that, you would need to create two different resource shares and split the resources among them, giving each set a different managed permission. There are two different types of managed permissions:

AWS RAM takes managed permissions as an input to author the resource-based policies for the resources you share.

Managed permission version

Any change to a managed permission is represented as a new version of that managed permission. The new version is the default for all new resource shares. Each managed permission always has one version designated as the default version. When you or AWS creates a new managed permission version, you must explicitly update the managed permission for each existing resource share. You can evaluate the changes before you apply them to your resource share in this step. All new resource shares will automatically use the new version of the managed permission for the corresponding resource type.

When you create or update a resource share, you can attach only the default version of the specified managed permission. For more information, see Updating AWS managed permissions to a newer version.