aoss service specific guidance

[tyson-trust]

For other services that support rcp's there is a service specific guidance document in the repo. Given that this is the first service to support RCP's where it doesn't support resource policied it would be interesting to see how AWS sees RCP's for this service getting used. I'm presuming it might be a confused deputy and/or IP restriction play here but it would be good to be called out.

[nitinkul1]

Hello,
We will take a look and get back on this soon.
Thanks for the patience.

[nitinkul1]

In general, you can use RCPs when you want to centrally enforce consistent access controls across resources in your organization. For example, you can use RCPs to help make sure that resources are accessible only from expected networks (as demonstrated in network_perimeter_rcp.json or to enforce HTTPS-only connections (as shown in https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps_examples.html#example-rcp-enforce-ssl, where you can list all services currently supported by RCPs). For services like aoss that don't support direct cross-account access through resource-based policies or other service built-in mechanisms, these controls only affect identities within the same account. In such cases, the same controls could be enforced using Service Control Policies (SCPs). Implementing them through RCPs might serve as a defense-in-depth measure or better align with your control enforcement strategy and auditing practices. We have also included aoss in our standard [identity_perimeter_rcp.json] (https://github.com/aws-samples/data-perimeter-policy-examples/blob/main/resource_control_policies/identity_perimeter_rcp.json) as a proactive measure - if the service implements resource-based policy support in the future, it will automatically be protected by the existing control that prevents external access to your resources.

For more non-data perimeter specific policy examples please refer to https://github.com/aws-samples/resource-control-policy-examples for more non-data perimeter specific policy examples

[nitinkul1]

Regarding the service-specific guidance, we plan to extend it to more services, so stay tuned!