Guardrails provides a rich set of capabilities for managing authentication of users, as well as authorization to cloud based services and resources.
Guardrails 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.
Permission Categories, Hierarchy & Inheritance
After a user has been authenticated and granted access, Guardrails Permission Levels determine what access they should be granted to which Accounts and Resources.
Permissions in Guardrails are designed to be consistent, convenient, secure and flexible.
Each area of Guardrails (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 Guardrails 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.
Guardrails permissions control what users are able to do through the Guardrails Console and API:
|Turbot/Owner||Manage permissions (including directories), manage mods AND|
|Turbot/Admin||Manage Guardrails resources and policies, including managing Guardrails 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 Guardrails CMDB is considered to be metadata, thus Turbot/ReadOnly and Turbot/Metadata are currently the same.
Cloud Provider Example - AWS Permissions
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.
Permissions & Grants
A permission is the combination of a permission type and level, for example:
A grant is the assignment of a permission to a Guardrails 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.
Note to Mod Authors
While Guardrails 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 Guardrails permission levels to their resources and APIs. To maintain consistency with other Guardrails 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