Add Access Control Profile Policies
This topic describes the operators, conditions, and rules for adding an access control policy, with examples.
An access control policy in an access control profile defines the resources and the conditions for accessing the resources. You can define conditions for accessing the following resources in an access control policy:
-
Devices
-
Network services
-
Tagging operations
The resources must be used as Device, NetworkService, and
Tagging in a policy.
For details of operations that can be access controlled on devices, network services, and tagging operations, see Table 1.
For information on adding an access control profile, see Access Control Profile Overview.
Condition Operators Supported in a Policy
Table 1 lists the operators that you can use in an access control policy.
| Operator | Description | Example |
|---|---|---|
|
StringEquals |
Use for string equals comparison of tags assigned to resources. More than one tag in a condition results in AND operation of the tags. When the example condition is used in a policy and assigned to a
network administrator (user in rest of the topic), the user will
have access to all devices and network services with tag
|
...
"conditions": {
"StringEquals": {
"device": "Juniper",
"site": "NY"
}
}
...
|
|
ForAnyValues:StringEquals |
Use for string equals comparison of tags assigned to resources. More than one tag in a condition results in OR operation of the tags. When the example condition is used in a policy and assigned to a
user, the user will have access to devices and services tagged
with |
...
"conditions": {
"ForAnyValues:StringEquals": {
"device": "Juniper",
"site": "NY"
}
}
...
|
|
StringResembles |
Use for string resembles comparison of tags assigned to resources. You can use the wildcard character asterisk (*) at the beginning or at the end of the tag key and tag value. More than one tag in a condition results in AND operation of the tags. When the example condition is used in a policy and assigned to a
user, the user will have access to devices and services tagged
with keys starting with
|
...
"conditions": {
"StringResembles": {
"depart*": "*st"
}
}
...
|
|
ForAnyValues:StringResembles |
Use for string resembles comparison of tags assigned to resources. You can use the wildcard character (*) at the beginning and end of the tag key and tag value. More than one tag in a condition results in OR operation of the tags. When the example condition is used in a policy and assigned to a
user, the user will have access to devices and services tagged
with keys starting with
|
...
"conditions": {
"ForAnyValues:StringResembles": {
"depart*": "*st",
"state": "*-maintenance",
}
}
...
|
StringResembles and
ForAnyValues:StringResembles operator supports wildcard
character (*) only at the beginning or at the end of a tag key or tag value. If
you use * as the tag value in a condition, then any value is matched. For
example:
-
us-*for matchingus-west,us-east, and so on -
*engineeringfor matchingtest-engineeringandsupport-engineering, and so on) -
*for matching any value likeus,europe, orK2 peak
Restrict Tagging Privilege using Condition Overrides
Routing Director allows a superuser to enable users to assign tags. See Privilege Escalation for details.
To restrict the privilege of assigning tags, Routing Director provides key override constructs. Use the key override constructs as follows:
-
internal.tag.keys—Use to provide a list of tag keys as conditions when tagging is specified as a resource in a policy.The below sample policy, when used in a profile and assigned to a user, will allow the user to: .
-
Assign tags with
departmentandrolekeys to resources. For example,department:Salesandrole:Sales -
Create tags with key
departmentandrole.
"policies": [ { "name": "policy1", "apis": [ "*" ], "resources": [ "Tagging" ], "conditions": { "StringEquals": { "internal.tag.keys": [ "department", "role" ] } } } ] -
-
internal.tag.constraints—Use to restrict the tagging operation to a specific set of resources instead of allowing unrestricted tagging on all resources.For example, the following condition in a policy would allow a user to access any resource tagged with
department:IT, CTO, or CFOANDvendor:Juniper, and tag such a resource only if the resource had keysregionortype."conditions": { "StringEquals": { "internal.tag.constraints": { "department": ["IT", "CTO", "CFO"], "vendor": ["Juniper"] }, "internal.tag.keys": ["region", "type"] } }Note:Keys specified in
internal.tag.keyscannot be the same as any of the keys specified ininternal.tag.constraints. This is to prevent privilege escalation. See Privilege Escalation for details on privilege escalation. -
internal.network-service.design-id—Use to provide service design IDs such asinfrastructure,elan-evpn-csm,l3vpn, and so on.For example, when you assign the following profile to a user, the user can create, update, or delete L3VPN service instances.
{ "name": "profile1", "description": "Profile to allow access to l3vpn service instances", "version": "1.0.0", "reference": "Non-mandatory way to input user's references like ticket number which necessitated the change", "comment": "Non-mandatory way for user to input a comment like change reason", "effect": "Allow", "policies": [ { "name": "policy1", "apis": [ "*" ], "resources": [ "NetworkService" ], "conditions": { "StringEquals": { "internal.network-service.design-id": [ "l3vpn" ] } } } ] }
Rules for Adding Policies to a Profile
You must consider the following points while creating an access control policy. Otherwise, Routing Director considers the policies as ambiguous:
- An access control policy with
Taggingresource must contain at least oneinternal.tag.keysconstruct. Theinternal.tag.keysconstruct should not be combined with other tagging conditions in the same condition block. This is to prevent privilege escalation. If you combineinternal.tag.keysconstruct and other tagging conditions in the same condition block, Routing Director considers the policy as ambiguous and does not process it.For example, when the following profile is applied to a user, the user can assign
departmentandvendortags to any device or network service. However, theinternal-tag-constraintsrestricts the user to assign thedepartmentandvendortags to resources withregion:US, region:Canadaorregion:Francetag.{ "name": "profile1", "description": "Profile to allow tagging resources with department and vendor tags. "version": "1.0.0", "reference": "Non-mandatory way to input user's references like ticket number which necessitated the change", "comment": "Non-mandatory way for user to input a comment like change reason", "effect": "Allow", "policies": [ { "name": "policy1", "apis": [ "*" ], "resources": [ "Tagging" ], "conditions": { "StringEquals": { "internal.tag.keys": [ "department", "vendor" ], "internal.tag.constraints": { "region": ["US", "Canada", "France"], } } } } ] } -
If the
resourceslist includes a network service, then the condition must includeinternal.network-service.design-idto indicate the service design ID that a user can access.For example, when the policy is applied to a user, the user can create, update, or delete a service instance of service design type elan-evpn-csm tagged with the
region:europetag."policies": [ { "name": "policy1", "apis": [ "*" ], "resources": [ "NetworkService" ], "conditions": { "StringEquals": { "internal.network-service.design-id": [ "elan-evpn-csm" ], "region": "europe" } } } ] If the
resourceslist includes a device, the policyconditionsshould include at least one tag for the device.For example, when the policy is applied to a user, the user can access devices with tag
For example:region:Europe or MiddleEastANDrole:PE."policies": [ { "name": "policy1", "apis": [ "*" ], "resources": [ "Device" ], "conditions": { "StringEquals": { "region": [ "Europe", "MiddleEast" ], "role": "PE" } } } ]-
Use of wildcards for
internal.network-service.design-idconstruct when usingStringResemblesandForAnyValues:StringResemblesoperator is not supported.For example, Routing Director would not be able to resolve the following policy:
"policies": [ { "name": "policy1", "apis": [ "*" ], "resources": [ "NetworkService" ], "conditions": { "StringResembles": { "internal.network-service.design-id": [ "el*" ], "region": "europe" } } } ] -
Do not start a tagging policy condition with the
ForAnyValuesoperator.For example, Routing Director would not be able to resolve the following policy:
"policies": [ { "name": "policy1", "apis": [ "*" ], "resources": [ "Tagging" ], "conditions": { "ForAnyValues:StringEquals": { "department": [ "Test" ] "instance": [ "POC" ] } } } ] -
Use wildcard comparison only with StringResembles or ForAnyValues:StringResembles operators. With StringEquals or ForAnyValues:StringEquals, the comparison is always string comparison even if you use wildcard characters.
-
The same tag keys cannot be used in the
internal.tag.keysandinternal.tag.constraints. This is to prevent privilege escalation. Useinternal.tag.keysonly with theStringEqualsoperator.For example, the following condition in a policy would allow a user to access any resource tagged with
department:IT, CTO, or CFOANDvendor:Juniper, and tag such a resource only with keysregionandtype."conditions": { "StringEquals": { "internal.tag.constraints": { "department": ["IT", "CTO", "CFO"], "vendor": ["Juniper"] }, "internal.tag.keys": ["region", "type"] } }