Turbot provides a rich set of capabilities for managing authentication of users, as well as authorization to cloud based services and resources.
Turbot integrates with the native Identity and Access Management solutions for the cloud provider but takes a loosely prescriptive approach to managing access -- we attempt to provide a well-defined framework that allows flexibility in implementation while greatly simplifying the management of permissions and policies.
After a user has been authenticated and granted access, Turbot Permission Levels determine what access they should be granted to which Accounts and Resources.
Permissions in Turbot are designed to be consistent, convenient, secure and flexible.
Each area of Turbot (e.g. Folder, AWS, S3) defines a (sub)set of Permission Levels that are consistently defined into specific categories.
The set of possible levels is consistent across services (though not all services have all levels). Permissions levels are cumulative, where each level includes all the permissions of the level(s) before it.
Permissions Levels, from lowest to highest are as follows:
- User: Can log in, but no rights
- Metadata: Read metadata
- ReadOnly: Read metadata and data
- Operator: Read metadata and data, make low-med risk changes
- Admin: Read metadata and data, make high risk changes
- Owner: Read metadata and data, make high risk changes, manage access, modify IAM resources
At the provider level, there is a special SuperUser level. Users assigned SuperUser permissions have unlimited access.
- SuperUser has full access to all services, even those that Turbot doesn't define permissions for.
- Lockdown policies do not apply to SuperUser.
- There are are no SuperUser levels for individual services, only the AWS Account or Google project.
Turbot permissions control what users are able to do through the Turbot Console and API:
|Turbot/Owner||Manage permissions (including directories), manage mods AND|
|Turbot/Admin||Manage Turbot resources and policies, including managing Turbot folders, AWS Accounts, GCP Projects, Azure Subscriptions, etc AND|
|Turbot/Operator||Run policy values & controls AND|
|Turbot/ReadOnly||View resource data in the CMDB*** AND|
|Turbot/Metadata||View resource data in the CMDB*** AND|
|Turbot/User||Log into the console|
*** At present, all the resource data stored in the Turbot CMDB is considered to be metadata, thus Turbot/ReadOnly and Turbot/Metadata are currently the same.
AWS permissions are specific to the service they are granting permissions for while following the general guidelines listed above. For instance, AWS/EC2/Admin allows users to launch and terminate instances (high risk changes) while AWS/EC2/Operator allows users to stop and start instances (medium risk changes):
|AWS/SuperUser||Allows full access permissions to the service with no preventative controls.|
|AWS/Owner||Manage permissions in AWS, e.g., management of AWS IAM users, groups, roles, and policies AND|
|AWS/Admin||Perform high to medium risk changes, e.g., creating and deleting resources, policy management AND|
|AWS/Operator||Perform medium to low risk changes, e.g., stopping and starting resources, tag management, snapshot management AND|
|AWS/ReadOnly||Read data, e.g., S3 key contents AND|
|AWS/Metadata||Read configuration data and metadata, e.g., describe instance configurations, list buckets.|
The permissions levels are applied to permission types, which define the types of resources or services to which they will apply. For example, AWS permissions types apply to all the resources within an AWS account, whereas AWS/S3 permissions apply only to S3 objects such as buckets.
A permission is the combination of a permission type and level, for example:
A grant is the assignment of a permission to a Turbot user or group on a resource or resource group. For instance:
- Nathan is granted
AWS/Adminon folder A
- The Ops group is granted
AWS/EC2/Operatoron AWS account aab
Note that a grant does not have to be an active grant: a grant can be explicitly activated or deactivated. A grant activation can be set to expire at a specific time, allowing for time-bound temporary privilege escalation.
While Turbot provides a centralized mechanism for granting permissions, as well as a framework for defining permissions, it is up to the mod author to determine how to apply the Turbot permission levels to their resources and APIs. To maintain consistency with other Turbot mods, you should follow the same guidelines for defining which level to assign a given action:
Does the action read, list or describe only metadata properties? If so, this is likely a Metadata permission. Examples include:
- Listing the buckets in an account or project
- Viewing information about whether a virtual machine is running
Does the action read (but not write) data within a resource? If so, this is likely a ReadOnly permission. Examples include:
- Getting or listing the objects inside a bucket
- Reading log file entries
- Querying a database
Can the operation be considered low-medium risk? Does it change the state of resources in ways that are reversible, have no impact on how the resource operates, and don't permanently destroy primary data? If so, this is likely an Operator permission. Examples include:
- Powering up/down VM instances
- Managing tags
- Managing snapshots / backups
Can the operation be considered med-high risk, potentially permanently changing or deleting resources or data? If so, this is likely an Administrator permission. Examples include:
- Creating or deleting VM instances, databases or other cloud resources
- Modifying network routing or gateways
- Managing policies
Does the operation manage permissions? If so, this is likely an Owner permission. Examples include:
- Managing Users, Roles and Policies
- Managing directories and authentication
Does the technology have a mode that is completely unrestricted? If so, this should be reserved for the SuperUser level. Examples include:
- Root Login / sudo to root