Permission Policy Examples
This page collects reusable examples of API7 Gateway permission policies, grouped by use case. 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.
Basic access patterns
Common starting points for API7 Gateway access control: broad platform access, read-only visibility, gateway-group scoped permissions, deny overrides, and label-scoped environment administration.
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"
}
]
}
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. Both statements use a MatchLabel condition on gateway_group_label: on the first statement it scopes management to existing groups labeled type: production, and on the second statement it scopes creation to requests whose body sets the same type: production label, so the user cannot create gateway groups outside the intended scope.
{
"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"
],
"conditions": {
"gateway_group_label": {
"type": "MatchLabel",
"options": {
"key": "type",
"operator": "exact_match",
"value": "production"
}
}
},
"effect": "allow"
}
]
}
Service and plugin operations
Patterns for operators who manage service templates, the corresponding published services across gateway groups, and custom plugins.
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.
API7 Gateway distinguishes between a Service Template ID and a Published Service ID:
- A service template has only a
Service Template ID. The same template can be published to multiple gateway groups. - Each publication of that template into a gateway group is a published service with its own
Published Service ID, which is unique to that gateway group.
The publishedservice/<id> segment of the ARN is matched against the Published Service ID, not the Service Template ID. Use the <.*> wildcard (as in the example below) when you want a single statement to cover every published service across gateway groups.
{
"statement": [
{
"resources": [
"arn:api7:gateway:servicetemplate/{service_template_id}"
],
"actions": [
"<.*>"
],
"effect": "allow"
},
{
"resources": [
"arn:api7:gateway:gatewaygroup/<.*>/publishedservice/<.*>"
],
"actions": [
"<.*>"
],
"effect": "allow"
},
{
"resources": [
"arn:api7:gateway:gatewaygroup/<.*>/publishedservice/*"
],
"actions": [
"gateway:CreatePublishedService",
"gateway:PublishServices"
],
"effect": "allow"
},
{
"resources": [
"arn:api7:gateway:gatewaygroup/<.*>"
],
"actions": [
"gateway:GetGatewayGroup",
"gateway:GetGlobalPluginRule",
"gateway:GetPluginMetadata"
],
"effect": "allow"
}
]
}
The third statement grants gateway:CreatePublishedService and gateway:PublishServices on gatewaygroup/<.*>/publishedservice/*, which is broader than the per-template scope of the other statements: at publish time the Published Service ID does not exist yet, so the ARN cannot be narrowed to a specific service. If you need to restrict who can publish or sync services, use a service_label MatchLabel condition on those actions (as in the label-based variant below) so that the request body must carry the matching service label.
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"
}
]
}
IAM and governance
Patterns for IAM administration and governance controls: role-management access, explicit deny guardrails, and permission boundaries for delegated administrators.
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"
}
]
}
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"
}
]
}
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 uses the AllOfStrings condition to require that the user's permission_boundaries context contains exactly the listed permission policy IDs — neither more nor fewer. In this case the user can only manage IAM users when the active boundary set is exactly {boundary_policy_id_1, boundary_policy_id_2}.
Attach this policy to a user via PUT /api/users/{user_id}/boundaries, passing the list of permission policy IDs that make up that user's boundary set. The values in options must be the IDs of the boundary policies that were assigned to the user.
{
"statement": [
{
"resources": [
"arn:api7:iam:user/<.*>"
],
"actions": [
"iam:InviteUser",
"iam:UpdateUser",
"iam:DeleteUser"
],
"conditions": {
"permission_boundaries": {
"type": "AllOfStrings",
"options": ["{boundary_policy_id_1}", "{boundary_policy_id_2}"]
}
},
"effect": "allow"
}
]
}
Portal management
Patterns for Developer Portal administration and API product ownership.
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 fully manage API products, view developer accounts, and approve developer sign-ups, while keeping read-only visibility into portal configuration. It does not grant subscription-management actions or broader portal/DCR provider administration, so this example fits product owners who curate API offerings and onboard developers but should not reshape 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"
}
]
}
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.