We use AWS Identity and Access Management (IAM) to manage permissions for the deployed services. AWS IAM controls who (authenticated entity/user) can do what (permission) and to whom (resource).
IAM Policies define what can be done and to whom.
*Policies can be grouped in IAM Roles; they can also be attached to a user, or to another entity as an inline policy.
- Roles can be assigned to IAM users.
- Code running inside AWS (like ECS containers or lambda functions), has permissions restricted via the same mechanisms (IAM roles and policies).
Single-Tenant deployments from ServiceCatalog must be performed by a user with Admin rights in the target AWS account. During deployment, CloudFormation creates various roles and policies that are then attached to our resources, allowing, for instance, a service to publish messages to a queue, or a lambda function to write data to an S3 bucket.
When assigning permissions, TetraScience follows the principle of least privilege. Least privilege gives each entity the minimum permissions required to do the job and no more. Therefore
- TetraScience does NOT create any IAM users via CloudFormation.
- TetraScience do NOT grant any cross-account permissions.
- All the roles and policies are defined in CloudFormation templates, which are shared with the customers and can be inspected at will.
By default, TetraScience engineers have no access to the deployed infrastructure and data. However, we strongly recommended for them to be given at least read-only CloudWatch logs access for troubleshooting and root cause analysis.
Updated over 1 year ago