Permission Policy Examples
This page collects reusable examples of API7 Gateway permission policies. Each example focuses on a common real-world access control scenario. For the exact JSON schema and field definitions, see Permission Policies and Boundaries; for the full catalog of allowed actions and resources, see Permission Policy Actions and Resources.
Policy document structure
When you create a permission policy via the Admin API (POST /api/permission_policies), the request body must be a complete PermissionPolicy object with name, optional desc and labels, and a policy_document wrapper around the statement array:
{
"name": "production-readonly",
"desc": "Read-only access to production gateway groups.",
"labels": {
"team": "sre"
},
"policy_document": {
"statement": [
{
"effect": "allow",
"resources": [
"arn:api7:gateway:gatewaygroup/<.*>"
],
"actions": [
"<.*>Get<.*>"
]
}
]
}
}
The examples below focus on the policy_document portion so that each example stays concise and comparable. When submitting them through the Admin API, wrap each statement array inside the envelope shown above.
Full Access to All Resources
This policy grants unrestricted access to all resources and actions within API7 Gateway. The <.*> wildcard in both resources and actions signifies "all". This is the most permissive policy and is typically reserved for super administrators.
{
"statement": [
{
"resources": [
"<.*>"
],
"actions": [
"<.*>"
],
"effect": "allow"
}
]
}
View-only to All Resources
This policy allows a user to view all resources but not make any changes. The actions are restricted to those containing "Get", which typically corresponds to read-only operations. This is useful for roles that need visibility across the system without modification privileges.
{
"statement": [
{
"resources": [
"<.*>"
],
"actions": [
"<.*>Get<.*>"
],
"effect": "allow"
}
]
}
View-only to Specific Gateway Groups
This policy grants read-only access to a specific list of Gateway Groups and the services published within them. It uses the unique gateway group ID to identify each resource. This is ideal for users who need to monitor specific environments, like production or testing, without the ability to alter configurations.
{
"statement": [
{
"resources": [
"arn:api7:gateway:gatewaygroup/{gateway group id 1}",
"arn:api7:gateway:gatewaygroup/{gateway group id 2}"
],
"actions": [
"<.*>Get<.*>"
],
"effect": "allow"
},
{
"resources": [
"arn:api7:gateway:gatewaygroup/{gateway group id 1}/publishedservice/<.*>",
"arn:api7:gateway:gatewaygroup/{gateway group id 2}/publishedservice/<.*>"
],
"actions": [
"<.*>Get<.*>"
],
"effect": "allow"
}
]
}
Full Access to Specific Gateway Groups
This policy provides complete control over specified Gateway Groups and their associated services. Multiple statements in a policy are combined with an "OR" relationship, meaning if any statement allows an action, it is permitted. This is suitable for environment-specific administrators, such as a production operations team.
{
"statement": [
{
"resources": [
"arn:api7:gateway:gatewaygroup/{gateway group id 1}",
"arn:api7:gateway:gatewaygroup/{gateway group id 2}"
],
"actions": [
"<.*>"
],
"effect": "allow"
},
{
"resources": [
"arn:api7:gateway:gatewaygroup/{gateway group id 1}/publishedservice/<.*>",
"arn:api7:gateway:gatewaygroup/{gateway group id 2}/publishedservice/<.*>"
],
"actions": [
"<.*>"
],
"effect": "allow"
}
]
}
Full Access to Specific Gateway Groups except Consumer Credentials
This policy grants broad permissions to specific Gateway Groups but explicitly denies the ability to manage consumer credentials. It demonstrates the "deny overrides allow" principle, where a deny effect takes precedence over any allow statements for the same resource and action. This is a crucial security measure to protect sensitive consumer data.
{
"statement": [
{
"resources": [
"arn:api7:gateway:gatewaygroup/{gateway group id 1}",
"arn:api7:gateway:gatewaygroup/{gateway group id 2}"
],
"actions": [
"<.*>"
],
"effect": "allow"
},
{
"resources": [
"arn:api7:gateway:gatewaygroup/{gateway group id 1}/publishedservice/<.*>",
"arn:api7:gateway:gatewaygroup/{gateway group id 2}/publishedservice/<.*>"
],
"actions": [
"<.*>"
],
"effect": "allow"
},
{
"resources": [
"arn:api7:gateway:gatewaygroup/<.*>/consumer/<.*>"
],
"actions": [
"gateway:GetConsumerCredential",
"gateway:UpdateConsumerCredential",
"gateway:DeleteConsumerCredential"
],
"effect": "deny"
}
]
}
Service Manager
This policy is designed for a "Service Manager" role who can manage specific services across all Gateway Groups. This includes modifying service templates, publishing services, and syncing them between groups. It grants broad permissions to specific service templates and their corresponding published services, while also providing necessary read access to Gateway Groups and global plugin rules to avoid conflicts.
Please learn the difference between ServiceTemplateID and ServiceID
{
"statement": [
{
"resources": [
"arn:api7:gateway:servicetemplate/{service template id}"
],
"actions": [
"<.*>"
],
"effect": "allow"
},
{
"resources": [
"arn:api7:gateway:gatewaygroup/<.*>/publishedservice/{service template id}"
],
"actions": [
"<.*>"
],
"effect": "allow"
},
{
"resources": [
"arn:api7:gateway:gatewaygroup/<.*>"
],
"actions": [
"gateway:GetGatewayGroup",
"gateway:GetGlobalPluginRule",
"gateway:GetPluginMetadata"
],
"effect": "allow"
}
]
}
Alternatively, you can use labels for more dynamic and scalable management of multiple services. This policy grants the same service management permissions but uses a MatchLabel condition to apply them to all services with the label team: enterprise.
{
"statement": [
{
"resources": [
"arn:api7:gateway:servicetemplate/<.*>"
],
"actions": [
"<.*>"
],
"conditions": {
"service_label": {
"type": "MatchLabel",
"options": {
"key": "team",
"operator": "exact_match",
"value": "enterprise"
}
}
},
"effect": "allow"
},
{
"resources": [
"arn:api7:gateway:gatewaygroup/<.*>/publishedservice/<.*>"
],
"actions": [
"<.*>"
],
"conditions": {
"service_label": {
"type": "MatchLabel",
"options": {
"key": "team",
"operator": "exact_match",
"value": "enterprise"
}
}
},
"effect": "allow"
},
{
"resources": [
"arn:api7:gateway:gatewaygroup/<.*>"
],
"actions": [
"gateway:GetGatewayGroup"
],
"effect": "allow"
}
]
}
Manage Custom Plugins
This policy grants permissions to manage custom plugins within the gateway settings. It allows any action that includes "CustomPlugin", providing full control over the lifecycle of custom plugins.
{
"statement": [
{
"resources": [
"arn:api7:gateway:gatewaysetting/*"
],
"actions": [
"gateway:<.*>CustomPlugin<.*>"
],
"effect": "allow"
}
]
}
Role Manager
This policy is for a "Role Manager" who is responsible for user and role administration. It grants full permissions to manage users, roles, and permission policies, allowing them to invite/delete users, reset passwords, design custom roles, and assign roles to users.
{
"statement": [
{
"resources": [
"arn:api7:iam:user/<.*>"
],
"actions": [
"<.*>"
],
"effect": "allow"
},
{
"resources": [
"arn:api7:iam:role/<.*>"
],
"actions": [
"<.*>"
],
"effect": "allow"
},
{
"resources": [
"arn:api7:iam:permissionpolicy/<.*>"
],
"actions": [
"<.*>"
],
"effect": "allow"
}
]
}
Create and Manage Production Gateway Groups
This policy allows a user to create new Gateway Groups and fully manage existing Gateway Groups that are labeled as "production". The conditions block filters the scope of the permissions, ensuring that the user can only affect resources with the specified label. This is a powerful way to enforce environment-specific access control.
{
"statement": [
{
"resources": [
"arn:api7:gateway:gatewaygroup/<.*>"
],
"actions": [
"<.*>"
],
"conditions": {
"gateway_group_label": {
"type": "MatchLabel",
"options": {
"key": "type",
"operator": "exact_match",
"value": "production"
}
}
},
"effect": "allow"
},
{
"resources": [
"arn:api7:gateway:gatewaygroup/*"
],
"actions": [
"gateway:CreateGatewayGroup"
],
"effect": "allow"
}
]
}
Full Resource Access with License Update Restriction
This policy provides a user with broad access to all resources while explicitly denying the ability to update the license. This is another example of the "deny overrides allow" rule and is a common security practice to prevent unauthorized changes to critical system settings like licensing. The deny statement ensures that even with full allow permissions on everything, the specific UpdateLicense action is prohibited.
{
"statement": [
{
"resources": [
"<.*>"
],
"actions": [
"<.*>"
],
"effect": "allow"
},
{
"resources": [
"arn:api7:iam:organization/*"
],
"actions": [
"iam:UpdateLicense"
],
"effect": "deny"
}
]
}
Portal Manager
This policy is designed for a "Portal Manager" role who is responsible for managing API Portal resources, including portals, DCR providers, API products, developers, and subscriptions. This role can create and manage API products, configure DCR providers, approve developer subscriptions, and oversee the entire API Portal lifecycle.
{
"statement": [
{
"resources": [
"arn:api7:portal:portal/<.*>"
],
"actions": [
"<.*>"
],
"effect": "allow"
},
{
"resources": [
"arn:api7:portal:dcrprovider/<.*>"
],
"actions": [
"<.*>"
],
"effect": "allow"
}
]
}
API Product Manager
This policy is for an "API Product Manager" role who can manage API products and view developers and subscriptions, but cannot manage portals or developer accounts directly. This allows for a separation of duties where product managers can focus on curating API offerings without having administrative control over the portal infrastructure.
{
"statement": [
{
"resources": [
"arn:api7:portal:portal/<.*>/apiproduct/<.*>"
],
"actions": [
"<.*>"
],
"effect": "allow"
},
{
"resources": [
"arn:api7:portal:portal/<.*>/developer/<.*>"
],
"actions": [
"portal:GetDeveloper",
"portal:ApproveDeveloperSignUp"
],
"effect": "allow"
},
{
"resources": [
"arn:api7:portal:portal/<.*>"
],
"actions": [
"portal:GetPortal"
],
"effect": "allow"
}
]
}
Permission Boundary for a Delegated Administrator
A permission boundary is a permission policy applied directly to a user to cap the maximum permissions that user can ever have, regardless of the roles they hold. The following example enforces a boundary named production-boundary using the AllOfStrings condition — it matches only when every string listed in options is present in the request context's permission_boundaries key.
Attach this policy to a user via PUT /api/users/{user_id}/boundaries so that the user cannot manage any IAM user unless their organization has granted both the production-boundary and audit-boundary contexts.
{
"statement": [
{
"resources": [
"arn:api7:iam:user/<.*>"
],
"actions": [
"iam:InviteUser",
"iam:UpdateUser",
"iam:DeleteUser"
],
"conditions": {
"permission_boundaries": {
"type": "AllOfStrings",
"options": ["production-boundary", "audit-boundary"]
}
},
"effect": "allow"
}
]
}
Additional Resources
- Permission Policies and Boundaries — full JSON syntax, statement fields, and condition types.
- Permission Policy Actions and Resources — the complete catalog of supported actions and resource ARNs.
- Role-Based Access Control — how roles, users, and policies fit together.