# Security in AWS Service Catalog Cloud security at AWS is the highest priority. As an AWS customer, you benefit from a data center and network architecture that is built to meet the requirements of the most security-sensitive organizations. Security is a shared responsibility between AWS and you. The [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) describes this as security *of* the cloud and security *in* the cloud: + **Security of the cloud** – AWS is responsible for protecting the infrastructure that runs AWS services in the AWS Cloud. AWS also provides you with services that you can use securely. Third-party auditors regularly test and verify the effectiveness of our security as part of the [AWS Compliance Programs](https://aws.amazon.com/compliance/programs/). To learn about the compliance programs that apply to AWS Service Catalog, see [AWS Services in Scope by Compliance Program](https://aws.amazon.com/compliance/services-in-scope/) + **Security in the cloud** – Your responsibility is determined by the AWS service that you use. You are also responsible for other factors including the sensitivity of your data, your company’s requirements, and applicable laws and regulations. This documentation helps you understand how to apply the shared responsibility model when using AWS Service Catalog. The following topics show you how to configure AWS Service Catalog to meet your security and compliance objectives. You also will be introduced to other AWS services that help you to monitor and secure your AWS Service Catalog resources. **Topics** + [Data Protection in AWS Service Catalog](data-protection.md) + [Identity and Access Management in AWS Service Catalog](controlling_access.md) + [Logging and Monitoring in AWS Service Catalog](logging-and-monitoring.md) + [Compliance Validation for AWS Service Catalog](service-catalog-compliance.md) + [Resilience in AWS Service Catalog](disaster-recovery-resiliency.md) + [Infrastructure Security in AWS Service Catalog](infrastructure-security.md) + [Security Best Practices for AWS Service Catalog](security-best-practices.md) # Data Protection in AWS Service Catalog The AWS [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) applies to data protection in AWS Service Catalog. As described in this model, AWS is responsible for protecting the global infrastructure that runs all of the AWS Cloud. You are responsible for maintaining control over your content that is hosted on this infrastructure. You are also responsible for the security configuration and management tasks for the AWS services that you use. For more information about data privacy, see the [Data Privacy FAQ](https://aws.amazon.com/compliance/data-privacy-faq/). For information about data protection in Europe, see the [AWS Shared Responsibility Model and GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) blog post on the *AWS Security Blog*. For data protection purposes, we recommend that you protect AWS account credentials and set up individual users with AWS IAM Identity Center or AWS Identity and Access Management (IAM). That way, each user is given only the permissions necessary to fulfill their job duties. We also recommend that you secure your data in the following ways: + Use multi-factor authentication (MFA) with each account. + Use SSL/TLS to communicate with AWS resources. We require TLS 1.2 and recommend TLS 1.3. + Set up API and user activity logging with AWS CloudTrail. For information about using CloudTrail trails to capture AWS activities, see [Working with CloudTrail trails](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) in the *AWS CloudTrail User Guide*. + Use AWS encryption solutions, along with all default security controls within AWS services. + Use advanced managed security services such as Amazon Macie, which assists in discovering and securing sensitive data that is stored in Amazon S3. + If you require FIPS 140-3 validated cryptographic modules when accessing AWS through a command line interface or an API, use a FIPS endpoint. For more information about the available FIPS endpoints, see [Federal Information Processing Standard (FIPS) 140-3](https://aws.amazon.com/compliance/fips/). We strongly recommend that you never put confidential or sensitive information, such as your customers' email addresses, into tags or free-form text fields such as a **Name** field. This includes when you work with AWS Service Catalog or other AWS services using the console, API, AWS CLI, or AWS SDKs. Any data that you enter into tags or free-form text fields used for names may be used for billing or diagnostic logs. If you provide a URL to an external server, we strongly recommend that you do not include credentials information in the URL to validate your request to that server. ## Protecting Data with Encryption ### Encryption at rest AWS Service Catalog uses Amazon S3 buckets and Amazon DynamoDB databases that are encrypted at rest using Amazon-managed keys. To learn more, refer to information about encryption at rest provided by Amazon S3 and Amazon DynamoDB. ### Encryption in transit AWS Service Catalog uses Transport Layer Security (TLS) and client-side encryption of information in transit between the caller and AWS. You can privately access AWS Service Catalog APIs from your Amazon Virtual Private Cloud (Amazon VPC) by creating VPC endpoints. With VPC endpoints, the routing between the VPC and AWS Service Catalog is handled by the AWS network without the need for an internet gateway, NAT gateway, or VPN connection. The latest generation of VPC endpoints used by AWS Service Catalog is powered by AWS PrivateLink, an AWS technology enabling the private connectivity between AWS services using Elastic Network Interfaces with private IPs in your VPCs. # Identity and Access Management in AWS Service Catalog Access to AWS Service Catalog requires credentials. Those credentials must have permission to access AWS resources, such as a AWS Service Catalog portfolio or product. AWS Service Catalog integrates with AWS Identity and Access Management (IAM) to enable you to grant AWS Service Catalog administrators the permissions they need to create and manage products, and to grant AWS Service Catalog end users the permissions they need to launch products and manage provisioned products. These policies are either created and managed by AWS or individually by administrators and end users. To control access, you attach these policies to users, groups, and roles that you use with AWS Service Catalog. ## Audience The permissions you have *with* AWS Identity and Access Management (IAM) can depend on the role you play in AWS Service Catalog. The permissions you have *through* AWS Identity and Access Management (IAM) can also depend on the role you play in AWS Service Catalog. **Administrator** - As a AWS Service Catalog administrator, you need full access to the administrator console and IAM permissions that allow you to perform tasks such as creating and managing portfolios and products, managing constraints, and granting access to end users. **End user** - Before your end users can use your products, you need to grant them permissions that give them access to the AWS Service Catalog end user console. They can also have permissions to launch products and manage provisioned products. **IAM administrator** - If you're an IAM administrator, you might want to learn details about how you can write policies to manage access to AWS Service Catalog. To view example AWS Service Catalog identity-based policies that you can use in IAM, see [AWS managed policies for AWS Service Catalog AppRegistry](security-iam-awsmanpol.md). # Identity-based policy examples for AWS Service Catalog **Topics** + [Console access for end users](#permissions-end-users-console) + [Product access for end users](#permissions-end-users-product) + [Example policies for managing provisioned products](#example-policies) ## Console access for end users The ****`AWSServiceCatalogEndUserFullAccess`**** and ****`AWSServiceCatalogEndUserReadOnlyAccess`**** policies grant access to the AWS Service Catalog end user console view. When a user who has either of these policies chooses AWS Service Catalog in the AWS Management Console, the end user console view displays the products they have permission to launch. Before end users can successfully launch a product from AWS Service Catalog to which you give access, you must provide them additional IAM permissions to allow them to use each of the underlying AWS resources in a product's AWS CloudFormation template. For example, if a product template includes Amazon Relational Database Service (Amazon RDS), you must grant the users Amazon RDS permissions to launch the product. To learn about how to enable end users to launch products while enforcing least-access permissions to AWS resources, see [Using AWS Service Catalog Constraints](constraints.md). If you apply the **`AWSServiceCatalogEndUserReadOnlyAccess`** policy, your users have access to the end user console, but they won't have the permissions that they need to launch products and manage provisioned products. You can grant these permissions directly to an end user using IAM, but if you want to limit the access that end users have to AWS resources, you should attach the policy to a launch role. You then use AWS Service Catalog to apply the launch role to a launch constraint for the product. For more information about applying a launch role, launch role limitations, and a sample launch role, see [AWS Service Catalog Launch Constraints](constraints-launch.md). **Note** If you grant users IAM permissions for AWS Service Catalog administrators, the administrator console view displays instead. Don't grant end users these permissions unless you want them to have access to the administrator console view. ## Product access for end users Before end users can use a product to which you give access, you must provide them additional IAM permissions to allow them to use each of the underlying AWS resources in a product's CloudFormation template. For example, if a product template includes Amazon Relational Database Service (Amazon RDS), you must grant the users Amazon RDS permissions to launch the product. If you apply the **`AWSServiceCatalogEndUserReadOnlyAccess`** policy, your users have access to the end user console view, but they won't have the permissions that they need to launch products and manage provisioned products. You can grant these permissions directly to an end user in IAM, but if you want to limit the access that end users have to AWS resources, you should attach the policy to a launch role. You then use AWS Service Catalog to apply the launch role to a launch constraint for the product. For more information about applying a launch role, launch role limitations, and a sample launch role, see [AWS Service Catalog Launch Constraints](constraints-launch.md). ## Example policies for managing provisioned products You can create custom policies to help meet the security requirements of your organization. The following examples describe how to customize the access level for each action with support for user, role, and account levels. You can grant users access to view, update, terminate, and manage provisioned products created only by that user or created by others also under their role or the account to which they are logged in. This access is hierarchical — granting account level access also grants role level access and user level access, while adding role level access also grants user level access but not account level access. You can specify these in the policy JSON using a `Condition` block as `accountLevel`, `roleLevel`, or `userLevel`. These examples also apply to access levels for AWS Service Catalog API write operations: `UpdateProvisionedProduct` and `TerminateProvisionedProduct`, and read operations: `DescribeRecord`, `ScanProvisionedProducts`, and `ListRecordHistory`. The `ScanProvisionedProducts` and `ListRecordHistory` API operations use `AccessLevelFilterKey` as input, and that key's values correspond to the `Condition` block levels discussed here (`accountLevel` is equivalent to an `AccessLevelFilterKey` value of "Account", `roleLevel` to "Role", and `userLevel` to "User"). For more information, see the [Service Catalog Developer Guide](https://docs.aws.amazon.com/servicecatalog/latest/dg/). **Topics** + [Full admin access to provisioned products](#full-admin) + [End-user access to provisioned products](#examples-end-user) + [Partial admin access to provisioned products](#partial-admin) ### Full admin access to provisioned products The following policy allows full read and write access to provisioned products and records within the catalog at the account level. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Action":[ "servicecatalog:*" ], "Resource":"*", "Condition": { "StringEquals": { "servicecatalog:accountLevel": "self" } } } ] } ``` ------ This policy is functionally equivalent to the following policy: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Action":[ "servicecatalog:*" ], "Resource":"*" } ] } ``` ------ Not specifying a `Condition` block in any policy for AWS Service Catalog is treated as the same as specifying `"servicecatalog:accountLevel"` access. Note that `accountLevel` access includes `roleLevel` and `userLevel` access. ### End-user access to provisioned products The following policy restricts access to read and write operations to only the provisioned products or associated records that the current user created. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "servicecatalog:DescribeProduct", "servicecatalog:DescribeProductView", "servicecatalog:DescribeProvisioningParameters", "servicecatalog:DescribeRecord", "servicecatalog:ListLaunchPaths", "servicecatalog:ListRecordHistory", "servicecatalog:ProvisionProduct", "servicecatalog:ScanProvisionedProducts", "servicecatalog:SearchProducts", "servicecatalog:TerminateProvisionedProduct", "servicecatalog:UpdateProvisionedProduct" ], "Resource": "*", "Condition": { "StringEquals": { "servicecatalog:userLevel": "self" } } } ] } ``` ------ ### Partial admin access to provisioned products The two policies below, if both applied to the same user, allow what might be called a type of "partial admin access" by providing full read-only access and limited write access. This means the user can see any provisioned product or associated record within the catalog's account but cannot perform any actions on any provisioned products or records that aren't owned by that user. The first policy allows the user access to write operations on the provisioned products that the current user created, but no provisioned products created by others. The second policy adds full access to read operations on provisioned products created by all (user, role, or account). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "servicecatalog:DescribeProduct", "servicecatalog:DescribeProductView", "servicecatalog:DescribeProvisioningParameters", "servicecatalog:ListLaunchPaths", "servicecatalog:ProvisionProduct", "servicecatalog:SearchProducts", "servicecatalog:TerminateProvisionedProduct", "servicecatalog:UpdateProvisionedProduct" ], "Resource": "*", "Condition": { "StringEquals": { "servicecatalog:userLevel": "self" } } } ] } ``` ------ ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "servicecatalog:DescribeRecord", "servicecatalog:ListRecordHistory", "servicecatalog:ScanProvisionedProducts" ], "Resource": "*", "Condition": { "StringEquals": { "servicecatalog:accountLevel": "self" } } } ] } ``` ------ # AWS managed policies for AWS Service Catalog AppRegistry ## AWS managed policy: `AWSServiceCatalogAdminFullAccess` You can attach `AWSServiceCatalogAdminFullAccess` to your IAM entities. AppRegistry also attaches this policy to a service role that allows AppRegistry to perform actions on your behalf. This policy grants *administrative* permissions that allow full access to the administrator console view and grants permission to create and manage products and portfolios. **Permissions details** This policy includes the following permissions. + `servicecatalog` – Allows principals full permissions to the administrator console view and the ability to create and manage portfolios and products, manage constraints, grant access to end users, and perform other administrative tasks within AWS Service Catalog. + `cloudformation`– Allows AWS Service Catalog full permissions to list, read, write, and tag AWS CloudFormation stacks. + `config`– Allows AWS Service Catalog limited permissions to portfolios, products, and provisioned products via AWS Config. + `iam`– Allows principals full permissions to view and create service users, gropus, or roles that are required for creating and managing products and portfolios. + `ssm` – Allows AWS Service Catalog to use AWS Systems Manager to list and read Systems Manager documents in the current AWS account and AWS Region. View the policy: [AWSServiceCatalogAdminFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSServiceCatalogAdminFullAccess.html). ## AWS managed policy: `AWSServiceCatalogAdminReadOnlyAccess` You can attach `AWSServiceCatalogAdminReadOnlyAccess` to your IAM entities. AppRegistry also attaches this policy to a service role that allows AppRegistry to perform actions on your behalf. This policy grants *read-only* permissions that allow full access to the administrator console view. This policy does not grant access to create or manage products and portfolios. **Permissions details** This policy includes the following permissions. + `servicecatalog` – Allows principals read-only permissions to the administrator console view. + `cloudformation`– Allows AWS Service Catalog limited permissions to list and read AWS CloudFormation stacks. + `config`– Allows AWS Service Catalog limited permissions to portfolios, products, and provisioned products via AWS Config. + `iam`– Allows principals limited permissions to view service users, groups, or roles that are required for creating and managing products and portfolios. + `ssm` – Allows AWS Service Catalog to use AWS Systems Manager to list and read Systems Manager documents in the current AWS account and AWS Region. View the policy: [AWSServiceCatalogAdminReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSServiceCatalogAdminReadOnlyAccess.html). ## AWS managed policy: `AWSServiceCatalogEndUserFullAccess` You can attach `AWSServiceCatalogEndUserFullAccess` to your IAM entities. AppRegistry also attaches this policy to a service role that allows AppRegistry to perform actions on your behalf. This policy grants *contributor* permissions that allow full access to the end user console view and grants permission to launch products and manage provisioned products. **Permissions details** This policy includes the following permissions. + `servicecatalog` – Allows principals full permissions to the end user console view and the ability to launch products and manage provisioned products. + `cloudformation`– Allows AWS Service Catalog full permissions to list, read, write, and tag AWS CloudFormation stacks. + `config`– Allows AWS Service Catalog limited permissions to list and read details about portfolios, products, and provisioned products via AWS Config. + `ssm` – Allows AWS Service Catalog to use AWS Systems Manager to read Systems Manager documents in the current AWS account and AWS Region. View the policy: [AWSServiceCatalogEndUserFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSServiceCatalogEndUserFullAccess.html). ## AWS managed policy: `AWSServiceCatalogEndUserReadOnlyAccess` You can attach `AWSServiceCatalogEndUserReadOnlyAccess` to your IAM entities. AppRegistry also attaches this policy to a service role that allows AppRegistry to perform actions on your behalf. This policy grants *read-only* permissions that allow read-only access to the end user console view. This policy does not grant permission to launch products or manage provisioned products. **Permissions details** This policy includes the following permissions. + `servicecatalog` – Allows principals read-only permissions to the end user console view. + `cloudformation`– Allows AWS Service Catalog limited permissions to list and read AWS CloudFormation stacks. + `config`– Allows AWS Service Catalog limited permissions to list and read details about portfolios, products, and provisioned products via AWS Config. + `ssm` – Allows AWS Service Catalog to use AWS Systems Manager to read Systems Manager documents in the current AWS account and AWS Region. View the policy: [AWSServiceCatalogEndUserReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSServiceCatalogEndUserReadOnlyAccess.html). ## AWS managed policy: `AWSServiceCatalogSyncServiceRolePolicy` AWS Service Catalog attaches this policy to the `AWSServiceRoleForServiceCatalogSync` service-linked role (SLR), allowing AWS Service Catalog to sync templates in an external repository to AWS Service Catalog products. This policy grants permissions that allows limited access to AWS Service Catalog actions (for example, API calls), and to other AWS service actions that AWS Service Catalog depends on. **Permissions details** This policy includes the following permissions. + `servicecatalog` – Allows the AWS Service Catalog artifact sync role limited access to AWS Service Catalog public APIs. + `codeconnections`– Allows the AWS Service Catalog artifact sync role limited access to CodeConnections public APIs. + `cloudformation`– Allows the AWS Service Catalog artifact sync role limited access to AWS CloudFormation public APIs. View the policy: [AWSServiceCatalogSyncServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSServiceCatalogSyncServiceRolePolicy.html). **Service-linked role details** AWS Service Catalog uses the permission details above for the `AWSServiceRoleForServiceCatalogSync` service-linked role that is created when a user creates or updates a AWS Service Catalog product that uses CodeConnections. You can modify this policy using the AWS CLI, AWS API, or through the AWS Service Catalog console. For more information on how to create, edit, and delete service-linked roles, refer to [Using service-linked roles (SLRs) for AWS Service Catalog](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/using-service-linked-roles). The permissions included in the `AWSServiceRoleForServiceCatalogSync` service-linked role allow AWS Service Catalog to perform the following actions on behalf of the customer. + `servicecatalog:ListProvisioningArtifacts` — Allows the AWS Service Catalog artifact sync role to list the provisioning artifacts for a given AWS Service Catalog product that is synced to a template file in a repository. + `servicecatalog:DescribeProductAsAdmin` — Allows the AWS Service Catalog artifact sync role to use the `DescribeProductAsAdmin` API to get details for a AWS Service Catalog product and its associated provisioned artifacts that are synced to a template file in a repository. The artifact sync role uses the output from this call to verify the product's service quota limit for provisioning artifacts. + `servicecatalog:DeleteProvisioningArtifact` — Allows the AWS Service Catalog artifact sync role to delete a provisioned artifact. + `servicecatalog:ListServiceActionsForProvisioningArtifact` — Allows the AWS Service Catalog artifact sync role to determine if Service Actions are associated with a provisioning artifact and ensure that the provisioning artifact is not deleted if a Service Action is associated. + `servicecatalog:DescribeProvisioningArtifact` — Allows the AWS Service Catalog artifact sync role to retrieve details from the `DescribeProvisioningArtifact` API, including the commit ID, which is provided in the `SourceRevisionInfo` output. + `servicecatalog:CreateProvisioningArtifact` — Allows the AWS Service Catalog artifact sync role to create a new provisioned artifact if a change is detected (for example, a git-push is committed) to the source template file in the external repository. + `servicecatalog:UpdateProvisioningArtifact` — Allows the AWS Service Catalog artifact sync role to update the provisioned artifact for a connected or synced product. + `codeconnections:UseConnection` — Allows the AWS Service Catalog artifact sync role to use the existing connection to update and sync a product. + `cloudformation:ValidateTemplate` — Allows the AWS Service Catalog artifact sync role limited access to AWS CloudFormation to validate the template format for the template that is being used in external repository and verify if CloudFormation can support the template. ## AWS managed policy: `AWSServiceCatalogOrgsDataSyncServiceRolePolicy` AWS Service Catalog attaches this policy to the `AWSServiceRoleForServiceCatalogOrgsDataSync` service-linked role (SLR), allowing AWS Service Catalog to sync with AWS Organizations. This policy grants permissions that allows limited access to AWS Service Catalog actions (for example, API calls), and to other AWS service actions that AWS Service Catalog depends on. **Permissions details** This policy includes the following permissions. + `organizations`— Allows the AWS Service Catalog data sync role limited access to AWS Organizations public APIs. View the policy: [AWSServiceCatalogOrgsDataSyncServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSServiceCatalogOrgsDataSyncServiceRolePolicy.html). **Service-linked role details** AWS Service Catalog uses the permission details above for the `AWSServiceRoleForServiceCatalogOrgsDataSync` service-linked role that is created when a user enables AWS Organizations shared portfolio access or creates a portfolio share. You can modify this policy using the AWS CLI, AWS API, or through the AWS Service Catalog console. For more information on how to create, edit, and delete service-linked roles, refer to [Using service-linked roles (SLRs) for AWS Service Catalog](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/using-service-linked-roles). The permissions included in the `AWSServiceRoleForServiceCatalogOrgsDataSync` service-linked role allow AWS Service Catalog to perform the following actions on behalf of the customer. + `organizations:DescribeAccount` — Allows the AWS Service Catalog Organizations Data Sync role to retrieve AWS Organizations-related information about the specified account. + `organizations:DescribeOrganization` — Allows the AWS Service Catalog Organizations Data Sync role to retrieve information about the organization that the user's account belongs to. + `organizations:ListAccounts` — Allows the AWS Service Catalog Organizations Data Sync role to list the accounts in the user's organization. + `organizations:ListChildren` — Allows the AWS Service Catalog Organizations Data Sync role to list all of the organizational units (UOs) or accounts that are contained in the specified parent OU or root. + `organizations:ListParents` — Allows the AWS Service Catalog Organizations Data Sync role to list the root or OUs that serve as the immediate parent of the specified child OU or account. + `organizations:ListAWSServiceAccessForOrganization` — Allows the AWS Service Catalog Organizations Data Sync role to retrieve a list of the AWS services that the user enabled to integrate with their organization. ## Deprecated policies The following managed policies are deprecated: + **ServiceCatalogAdminFullAccess** — Use **AWSServiceCatalogAdminFullAccess** instead. + **ServiceCatalogAdminReadOnlyAccess** — Use **AWSServiceCatalogAdminReadOnlyAccess** instead. + **ServiceCatalogEndUserFullAccess** — Use **AWSServiceCatalogEndUserFullAccess** instead. + **ServiceCatalogEndUserAccess** — Use **AWSServiceCatalogEndUserReadOnlyAccess** instead. Use the following procedure to ensure that your administrators and end users are granted permissions using the current policies. To migrate from the deprecated policies to the current policies, see [Adding and removing IAM identity permissions ](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html#add-policies-console)in *AWS Identity and Access Management User Guide*. ## AppRegistry updates to AWS managed policies View details about updates to AWS managed policies for AppRegistry since this service began tracking these changes. For automatic alerts about changes to this page, subscribe to the RSS feed on the AppRegistry Document history page. | Change | Description | Date | | --- | --- | --- | | [AWSServiceCatalogSyncServiceRolePolicy](#security-iam-awsmanpol-AWSServiceCatalogSyncServiceRolePolicy) – Update managed policy | AWS Service Catalog updated the `AWSServiceCatalogSyncServiceRolePolicy` policy to change `codestar-connections` to `codeconnections`. | May 7, 2024 | | [AWSServiceCatalogAdminFullAccess](#security-iam-awsmanpol-AWSServiceCatalogAdminFullAccess) – Update managed policy | AWS Service Catalog updated the `AWSServiceCatalogAdminFullAccess` policy to include permissions required for the AWS Service Catalog administrator to create the `AWSServiceRoleForServiceCatalogOrgsDataSync` service-linked role (SLR) in their account. | April 14, 2023 | | [AWSServiceCatalogOrgsDataSyncServiceRolePolicy](#security-iam-awsmanpol-AWSServiceCatalogOrgsDataSyncServiceRolePolicy) – New managed policy | AWS Service Catalog added the `AWSServiceCatalogOrgsDataSyncServiceRolePolicy`, which is attached to the `AWSServiceRoleForServiceCatalogOrgsDataSync` service-linked role (SLR), allowing AWS Service Catalog to sync with AWS Organizations. This policy allows limited access to AWS Service Catalog actions (for example, API calls), and to other AWS service actions that AWS Service Catalog depends on. | April 14, 2023 | | [AWSServiceCatalogAdminFullAccess](#security-iam-awsmanpol-AWSServiceCatalogAdminFullAccess) – Update managed policy | AWS Service Catalog updated the `AWSServiceCatalogAdminFullAccess` policy to include all permissions for the AWS Service Catalog Administrator and create compatibility with AppRegistry. | January 12, 2023 | | [AWSServiceCatalogSyncServiceRolePolicy](#security-iam-awsmanpol-AWSServiceCatalogSyncServiceRolePolicy) – New managed policy | AWS Service Catalog added the `AWSServiceCatalogSyncServiceRolePolicy` policy, which is attached to the `AWSServiceRoleForServiceCatalogSync` service-linked role (SLR). This policy allows AWS Service Catalog to sync templates in an external repository to AWS Service Catalog products. | November 18, 2022 | | [AWSServiceRoleForServiceCatalogSync](using-service-linked-roles.md#slr-permissions) – New service-linked role | AWS Service Catalog added the `AWSServiceRoleForServiceCatalogSync` service-linked role (SLR). This role is required for AWS Service Catalog to use CodeConnections and to create, update, and describe AWS Service Catalog Provisioning Artifacts for a product. | November 18, 2022 | | [AWSServiceCatalogAdminFullAccess](#security-iam-awsmanpol-AWSServiceCatalogAdminFullAccess) – Updated managed policy | AWS Service Catalog updated the `AWSServiceCatalogAdminFullAccess` policy to include all of the required permissions for a AWS Service Catalog Administrator. The policy identifies the specific actions administrator can take on all AWS Service Catalog resources, such as create, describe, delete, and more. Additionally, the policy was changed to support a recently launched feature, Attribute Based Access Control (ABAC) for AWS Service Catalog. ABAC allows you to use the `AWSServiceCatalogAdminFullAccess` policy as a template to allow or deny actions on AWS Service Catalog resources based on tags. For more information about ABAC, see [ What is ABAC for AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in *AWS Identity and Access Management*. | September 30, 2022 | | AppRegistry started tracking changes | AppRegistry started tracking changes for its AWS managed policies. | September 15, 2022 | # Using service-linked roles for AWS Service Catalog AWS Service Catalog uses AWS Identity and Access Management (IAM)[ service-linked roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role). A service-linked role is a unique type of IAM role that is linked directly to AWS Service Catalog. Service-linked roles are predefined by AWS Service Catalog and include all the permissions that the service requires to call other AWS services on your behalf. A service-linked role makes setting up AWS Service Catalog easier because you don’t have to manually add the necessary permissions. AWS Service Catalog defines the permissions of its service-linked roles, and unless defined otherwise, only AWS Service Catalog can assume its roles. The defined permissions include the trust policy and the permissions policy, and that permissions policy cannot be attached to any other IAM entity. You can delete a service-linked role only after first deleting their related resources. This protects your AWS Service Catalog resources because you can't inadvertently remove permission to access the resources. For information about other services that support service-linked roles, see [AWS Services That Work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) and look for the services that have **Yes **in the **Service-linked roles** column. Choose a **Yes** with a link to view the service-linked role documentation for that service. ## Service-linked role permissions for `AWSServiceRoleForServiceCatalogSync` AWS Service Catalog can use the service-linked role named **`AWSServiceRoleForServiceCatalogSync`** – This service-linked role is required for AWS Service Catalog to use CodeConnections and to create, update, and describe AWS Service Catalog Provisioning Artifacts for a product. The `AWSServiceRoleForServiceCatalogSync` service-linked role trusts the following services to assume the role: + `sync.servicecatalog.amazonaws.com` The role permissions policy named **AWSServiceCatalogSyncServiceRolePolicy** allows AWS Service Catalog to complete the following actions on the specified resources: + Action: `Connection` on `CodeConnections` + Action: `Create, Update, and Describe` on `ProvisioningArtifact` for a AWS Service Catalog product You must configure permissions to allow an IAM entity (such as a user, group, or role) to create, edit, or delete a service-linked role. For more information, see [Service-linked role permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) in the *IAM User Guide*. ### Creating the `AWSServiceRoleForServiceCatalogSync` service-linked role You do not need to manually create the `AWSServiceRoleForServiceCatalogSync` service-linked role. AWS Service Catalog creates the service-linked role for you automatically when you establish CodeConnections in the AWS Management Console, the AWS CLI, or the AWS API. **Important** This service-linked role can appear in your account if you completed an action in another service that uses the features supported by this role. Also, if you were using the AWS Service Catalog service before November 18, 2022, when it began supporting service-linked roles, then AWS Service Catalog created the `AWSServiceRoleForServiceCatalogSync` role in your account. To learn more, see [A new role appeared in my IAM account](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared). If you delete this service-linked role, and then need to create it again, you can use the same process to recreate the role in your account. When you establish CodeConnections, AWS Service Catalog creates the service-linked role for you again. You can also use the IAM console to create a service-linked role with the **synced AWS Service Catalog Products** use case. In the AWS CLI or the AWS API, create a service-linked role with the `sync.servicecatalog.amazonaws.com` service name. For more information, see [Creating a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#create-service-linked-role) in the *IAM User Guide*. If you delete this service-linked role, you can use this same process to create the role again. ## Service-linked role permissions for `AWSServiceRoleForServiceCatalogOrgsDataSync` AWS Service Catalog can use the service-linked role named **`AWSServiceRoleForServiceCatalogOrgsDataSync`** – This service-linked role is required for AWS Service Catalog organizations to stay in sync with AWS Organizations. The `AWSServiceRoleForServiceCatalogOrgsDataSync` service-linked role trusts the following services to assume the role: + `orgsdatasync.servicecatalog.amazonaws.com` The `AWSServiceRoleForServiceCatalogOrgsDataSync` service-linked role requires that you use the following trust policy in addition to the `AWSServiceCatalogOrgsDataSyncServiceRolePolicy` [managed policy](security-iam-awsmanpol.md#security-iam-awsmanpol-AWSServiceCatalogOrgsDataSyncServiceRolePolicy): ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "orgsdatasync.servicecatalog.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` ------ The role permissions policy named **AWSServiceCatalogOrgsDataSyncServiceRolePolicy** allows AWS Service Catalog to complete the following actions on the specified resources: + Action: `DescribeAccount`, `DescribeOrganization`, and `ListAWSServiceAccessForOrganization` on `Organizations accounts` + Action: `ListAccounts`, `ListChildren`, and `ListParent` on `Organizations accounts` You must configure permissions to allow an IAM entity (such as a user, group, or role) to create, edit, or delete a service-linked role. For more information, see [Service-linked role permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) in the *IAM User Guide*. ### Creating the `AWSServiceRoleForServiceCatalogOrgsDataSync` service-linked role You do not need to manually create the `AWSServiceRoleForServiceCatalogOrgsDataSync`service-linked role. AWS Service Catalog considers your action of enabling [Sharing with AWS Organizations](catalogs_portfolios_sharing_how-to-share.md#portfolio-sharing-organizations) or [Sharing a Portfolio](catalogs_portfolios_sharing_how-to-share.md) as permission for AWS Service Catalog to create a SLR in the background on your behalf. AWS Service Catalog creates the service-linked role for you automatically when you request `EnableAWSOrganizationsAccess` or `CreatePortfolioShare` in the AWS Management Console, the AWS CLI, or the AWS API. **Important** This service-linked role can appear in your account if you completed an action in another service that uses the features supported by this role. To learn more, see [A new role appeared in my IAM account](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared). If you delete this service-linked role, and then need to create it again, you can use the same process to recreate the role in your account. When you request `EnableAWSOrganizationsAccess` or `CreatePortfolioShare`, AWS Service Catalog creates the service-linked role for you again. ## Editing a service-linked role for AWS Service Catalog AWS Service Catalog does not allow you to edit the `AWSServiceRoleForServiceCatalogSync` or `AWSServiceRoleForServiceCatalogOrgsDataSync` service-linked roles. After you create a service-linked role, you cannot change the name of the role because various entities might reference the role. However, you can edit the description of the role using IAM. For more information, see [Editing a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) in the *IAM User Guide*. ## Deleting a service-linked role for AWS Service Catalog You can use the IAM console, the AWS CLI, or the AWS API to manually delete the `AWSServiceRoleForServiceCatalogSync` or `AWSServiceRoleForServiceCatalogOrgsDataSync` SLR. To do this, you must first manually remove all resources that are using the service-linked role (for example, any AWS Service Catalog products that are synced to an external repository), and then the service-linked role can be manually deleted. ## Supported regions for AWS Service Catalog service-linked roles AWS Service Catalog supports using service-linked roles in all of the regions where the service is available. For more information, see [AWS regions and endpoints](https://docs.aws.amazon.com/general/latest/gr/rande.html). **** | Region name | Region identity | Support in AWS Service Catalog | | --- | --- | --- | | US East (N. Virginia) | us-east-1 | Yes | | US East (Ohio) | us-east-2 | Yes | | US West (N. California) | us-west-1 | Yes | | US West (Oregon) | us-west-2 | Yes | | Africa (Cape Town) | af-south-1 | Yes | | Asia Pacific (Hong Kong) | ap-east-1 | Yes | | Asia Pacific (Jakarta) | ap-southeast-3 | Yes | | Asia Pacific (Mumbai) | ap-south-1 | Yes | | Asia Pacific (Osaka) | ap-northeast-3 | Yes | | Asia Pacific (Seoul) | ap-northeast-2 | Yes | | Asia Pacific (Singapore) | ap-southeast-1 | Yes | | Asia Pacific (Sydney) | ap-southeast-2 | Yes | | Asia Pacific (Tokyo) | ap-northeast-1 | Yes | | Canada (Central) | ca-central-1 | Yes | | Europe (Frankfurt) | eu-central-1 | Yes | | Europe (Ireland) | eu-west-1 | Yes | | Europe (London) | eu-west-2 | Yes | | Europe (Milan) | eu-south-1 | Yes | | Europe (Paris) | eu-west-3 | Yes | | Europe (Stockholm) | eu-north-1 | Yes | | Middle East (Bahrain) | me-south-1 | Yes | | South America (São Paulo) | sa-east-1 | Yes | | AWS GovCloud (US-East) | us-gov-east-1 | No | | AWS GovCloud (US-West) | us-gov-west-1 | No | # Troubleshooting AWS Service Catalog identity and access Use the following information to help you diagnose and fix common issues you might encounter when working with AWS Service Catalog and IAM. **Topics** + [I am not authorized to perform an action in AWS Service Catalog](#troubleshoot-one) + [I am not authorized to perform `iam:PassRole`](#troubleshoot-two) + [I want to allow people outside of my AWS account to access my AWS Service Catalog resources](#troubleshoot-five) ## I am not authorized to perform an action in AWS Service Catalog If the AWS Management Console tells you that you're not authorized to perform an action, then you must contact your administrator for assistance. Your administrator is the person that provided you with your sign-in credentials. The following example error occurs when the mateojackson user tries to use the console to view details about a fictional my-example-widget resource but does not have the fictional `aws:GetWidget` permissions. ``` User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: aws:GetWidget on resource: my-example-widget ``` In this case, Mateo asks his administrator to update his policies to allow him to access the `my-example-widget` resource using the `aws:GetWidget` action. ## I am not authorized to perform `iam:PassRole` If you receive an error that you're not authorized to perform the `iam:PassRole` action, then you must contact your administrator for assistance. Your administrator is the person that provided you with your user name and password. Ask that person to update your policies to allow you to pass a role to AWS Service Catalog. Some AWS services allow you to pass an existing role to that service, instead of creating a new service role or service-linked role. To do this, you must have permissions to pass the role to the service. The following example error occurs when a user named marymajor tries to use the console to perform an action in AWS Service Catalog. However, the action requires the service to have permissions granted by a service role. Mary does not have permissions to pass the role to the service. ``` User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole ``` In this case, Mary asks her administrator to update her policies to allow her to perform the iam:PassRole action. ## I want to allow people outside of my AWS account to access my AWS Service Catalog resources You can create a role that users in other accounts or people outside of your organization can use to access your resources. You can specify who is trusted to assume the role. For services that support resource-based policies or access control lists (ACLs), you can use those policies to grant people access to your resources. To learn more, consult the following: + To learn whether AWS Service Catalog supports these features, see [AWS Identity and Access Management in AWS Service Catalog](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/controlling_access.html) in the *AWS Service Catalog Administrator Guide*. + To learn how to provide access to your resources across AWS accounts that you own, see [Providing access to an IAM user in another AWS account that you own ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) in the *IAM User Guide*. + To learn how to provide access to your resources to third-party AWS accounts, see [Providing access to AWS accounts owned by third parties](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) in the *IAM User Guide*. + To learn how to provide access through identity federation, see [Providing access to externally authenticated users (identity federation)](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) in the *IAM User Guide*. + To learn the difference between using roles and resource-based policies for cross-account access, see [How IAM roles differ from resource-based policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_compare-resource-policies.html) in the *IAM User Guide*. # Controlling Access a AWS Service Catalog portfolio gives your administrators a level of access control for your groups of end users. When you add users to a portfolio, they can browse and launch any of the products in the portfolio. For more information, see [Managing Portfolios](catalogs_portfolios.md). ## Constraints Constraints control which rules are applied to your end users when launching a product from a specific portfolio. You use them to apply limits to products for governance or cost control. For more information about constraints, see [Using AWS Service Catalog Constraints](constraints.md). AWS Service Catalog launch constraints give you more control over permissions needed by an end user. When your administrator creates a launch constraint for a product in a portfolio, the launch constraint associates a role ARN that is used when your end users launch the product from that portfolio. Using this pattern, you can control access to AWS resource creation. For more information, see [AWS Service Catalog Launch Constraints](constraints-launch.md). # Logging and Monitoring in AWS Service Catalog AWS Service Catalog integrates with AWS CloudTrail, a service that captures all of the AWS Service Catalog API calls and delivers the log files to an Amazon S3 bucket that you specify. For more information, see [Logging AWS Service Catalog API Calls with CloudTrail.](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/logging-using-cloudtrail.html) You can also use notification constraints to set up Amazon SNS notifications about stack events. For more information, see [AWS Service Catalog Notification Constraints](constraints-notification.md). # Compliance Validation for AWS Service Catalog Third-party auditors assess the security and compliance of AWS Service Catalog as part of multiple AWS compliance programs, including the following: + System and Organization Controls (SOC) + Payment Card Industry Data Security Standard (PCI DSS) + Federal Risk and Authorization Management Program (FedRAMP) + Health Insurance Portability and Accountability Act (HIPAA) For a list of AWS services in scope of specific compliance programs, see [AWS Services in Scope by Compliance Program](https://aws.amazon.com/compliance/services-in-scope/). For general information, see [AWS Compliance Programs](https://aws.amazon.com/compliance/programs/). You can download third-party audit reports using AWS Artifact. For more information, see [Downloading Reports in AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html). Your compliance responsibility when using AWS Service Catalog depends on the sensitivity of your data, your company's compliance objectives, and applicable laws and regulations. AWS provides these resources to help with compliance: + [Security and Compliance Quick Start Guides](https://aws.amazon.com/quickstart/) – These deployment guides discuss architectural considerations and provide steps for deploying security- and compliance-focused baseline environments on AWS. + [Architecting for HIPAA Security and Compliance Whitepaper ](https://docs.aws.amazon.com/pdfs/whitepapers/latest/architecting-hipaa-security-and-compliance-on-aws/architecting-hipaa-security-and-compliance-on-aws.pdf) – This whitepaper describes how companies can use AWS to create HIPAA-compliant applications. + [AWS Compliance Resources](https://aws.amazon.com/compliance/resources/) – This collection of workbooks and guides could apply to your industry and location. + [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) – This AWS service assesses how well your resource configurations comply with internal practices, industry guidelines, and regulations. + [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) – This AWS service provides a comprehensive view of your security state within AWS that helps you check your compliance with security industry standards and best practices. # Resilience in AWS Service Catalog The AWS global infrastructure is built around AWS Regions and Availability Zones. AWS Regions provide multiple physically separated and isolated Availability Zones, which are connected with low-latency, high-throughput, and highly redundant networking. With Availability Zones, you can design and operate applications and databases that automatically fail over between Availability Zones without interruption. Availability Zones are more highly available, fault tolerant, and scalable than traditional single or multiple data center infrastructures. For more information about AWS Regions and Availability Zones, see [AWS Global Infrastructure](https://aws.amazon.com/about-aws/global-infrastructure/). In addition to the AWS global infrastructure, AWS Service Catalog offers AWS Service Catalog self-service actions. With self-service actions, customers can reduce administrative maintenance and end-user training while adhering to compliance and security measures. With self-service actions, as the administrator, you can enable end users to perform operational tasks such as backup and restore, troubleshoot issues, run approved commands, and request permissions in AWS Service Catalog. To learn more, see [AWS Service Catalog Service Actions](using-service-actions.md). # Infrastructure Security in AWS Service Catalog As a managed service, AWS Service Catalog is protected by AWS global network security. For information about AWS security services and how AWS protects infrastructure, see [AWS Cloud Security](https://aws.amazon.com/security/). To design your AWS environment using the best practices for infrastructure security, see [Infrastructure Protection](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html) in *Security Pillar AWS Well‐Architected Framework*. You use AWS published API calls to access AWS Service Catalog through the network. Clients must support the following: + Transport Layer Security (TLS). We require TLS 1.2 and recommend TLS 1.3. + Cipher suites with perfect forward secrecy (PFS) such as DHE (Ephemeral Diffie-Hellman) or ECDHE (Elliptic Curve Ephemeral Diffie-Hellman). Most modern systems such as Java 7 and later support these modes. With AWS Service Catalog, you can control the Regions in which data is stored. Portfolios and products are only available in the Regions in which you have made them available. You can use the `CopyProduct` API to copy a product to another Region. # Security Best Practices for AWS Service Catalog AWS Service Catalog provides a number of security features to consider as you develop and implement your own security policies. The following best practices are general guidelines and don’t represent a complete security solution. Because these best practices might not be appropriate or sufficient for your environment, treat them as helpful considerations rather than prescriptions. You can define rules that limit the parameter values that a user enters when launching a product. These rules are called template constraints because they constrain how the CloudFormation template for the product is deployed. You use a simple editor to create template constraints, and you apply them to individual products. AWS Service Catalog applies constraints when provisioning a new product or updating a product that is already in use. It always applies the most restrictive constraint among all constraints applied to the portfolio and the product. For example, consider a scenario where the product allows all Amazon EC2 instances to be launched and the portfolio has two constraints: one that allows all non-GPU type EC2 instances to be launched and one that allows only t1.micro and m1.small EC2 instances to be launched. For this example, AWS Service Catalog applies the second, more restrictive constraint (t1.micro and m1.small). You can limit the access end users have to AWS resources when you attach an IAM policy to a launch role. You then use AWS Service Catalog to create a launch constraint to use the role when launching the product. To learn more about managed policies for AWS Service Catalog, see [AWS Managed Policies for AWS Service Catalog.](security-iam-awsmanpol.md)