Create permissions and guardrails

Once you have defined your access requirements, you can begin writing policies that enforce permissions guardrails by using least privilege policies.

Creating policies and enforcing guardrails is the process of translating requirements into policies that define what users, applications, and systems can do. Writing effective permissions involves converting the requirements for each role or function within your organization when you defined your access requirements into policies for your systems.

What are permissions

Permissions are the specific actions that users, applications, or systems can take on resources. Permissions are typically defined in policies and used to control access to resources in a system.

You can grant or deny permissions based on various factors, including the user's role, group membership, the resources they access, and the context of the access request. For example, a user may have permission to read data from a database but not to write data to it.

Defining guardrails allows you to enforce policies at different levels of the organization, preventing you from granting excessive permissions to a user or system. This diagram shows an example of restricting permissions at various levels. The effective permissions for a user is a combination of permissions granted at the user, group, and organizational levels.

The following is an example of a database permission and AWS S3 bucket policy that follows least privilege:

GRANT SELECT ON ALL TABLES IN SCHEMA public TO readonly_user;

The PostgreSQL role readonly_user with the SELECT permission can select data from tables, but not write or modify data.

An example AWS IAM policy that follows least privilege allows read-only access to download files from the "company-reports" S3 bucket.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::company-reports",
                "arn:aws:s3:::company-reports/*"
            ]
        }
    ]
}

Define permissions as code

Where possible, define your permissions in policies as code. Defining permissions in policies as code allows you to version control your policies, track changes over time, and collaborate with your team. You can then use tools like HashiCorp's Terraform or Red Hat's Ansible to deploy and update your policies. Most systems support writing policies in JSON, YAML, or XML.

Some systems like HashiCorp's Vault and Sentinel support policies in custom languages like the HashiCorp Configuration Language (HCL). JSON is another widely supported format. HashiCorp Vault supports JSON based policies, in addition to HCL. AWS Identity and Access Management (IAM) supports JSON-based policies. Other systems like Active Directory may require scripting the policies in other languages like PowerShell to create Group Policy Objects (GPOs).

Terraform helps you manage your policies for supported tools and services, allowing you to define, update, and enforce policies as code. Using automation to manage policies ensures that your policies are consistent, auditable, and can be version controlled.

HashiCorp resources:

• Access controls with Vault policies
• Policy as code with Sentinel
• Create IAM policies with Terraform
• Use templates with Waypoint

External resources:

• Define, update, share, and enforce policies using code
• Introduction to policy as code with automation

Next steps

Following these documents in order ensures a logical progression through the key concepts and best practices, helping you build a strong foundation to build your identity and access management program.

• Define access requirements
• Grant least privilege
• Create permissions and guardrails (this document)
• Centralize identity management
• Implement strong sign-in workflows
• Use dynamic credentials
• Manage access lifecycle

In this section of Identity and access management, you learned the difference between granting excessive permission and how it relates to the concept of least privilege. Identity and access management is part of the Secure systems pillar.