Access Restrictions and Trusted Proxy IPs
To employ automation for managing the PCE environment, you can use API Keys created by an admin user and automate the PCE management tasks. Illumio provides a way to restrict the usage of these API keys by IP address so that you can block API requests coming in from non-allowed IP addresses.
Access Restrictions
Access restrictions are configurable entities and contain a list of up to 8 IPv4 IP addresses or CIDR blocks that specify the source IP addresses of the allowed clients. Only the global Org Owner can manage access restrictions in the organization, while other roles cannot edit nor view them.
The following rules apply to access restrictions:
Each access restriction can be applied to either one or both:
API requests authenticated by API keys
API requests authenticated by
Username/Passwordcredentials
The global Org Owners can edit an access restriction after it has been created by modifying the allowed IP list or the options. They can also assign access restrictions to Local and External Users. The API supports the update of access restrictions for a list of users.
Access restrictions are leader-owned configuration objects that are replicated to all supercluster regions.
Access restrictions are enforced as follows:
To enforce an API request, determine the user account for that API request using the API key or the user session token and then find the access restriction that is configured for that user. If no access restriction is assigned to the user, the API request proceeds.
If the client IP address for an API request does not satisfy the corresponding user's access restrictions, the request is rejected with a 401 error message.
Access restrictions are not enforced on some URLs (node_available, static JS/CSS content).
When a request is rejected due to unsatisfied access restrictions, it generates an Event that specifies a failure caused by an invalid source IP address, including the actual IP address and an appropriate error code (403).
Assignment to Users
Each Access Restriction is a configuration object that specifies a set of allow-list IP addresses or CIDR blocks, designating the allowed client IP address. It also specifies the types of API accesses that are restricted (those authenticated by API Keys or those authenticated by user session tokens).
The Org Owners create and manage access restrictions in their organizations so that there are a maximum of 50 access restrictions per organization. The Org Owners can assign a single access restriction to each Local or External User (by default, a user has no access restriction assigned).
Access Restriction Methods
Functionality | HTTP | URI |
|---|---|---|
Get a list of access restrictions. |
|
|
Get a specific access restriction. |
|
|
Create an access restrictio.n |
|
|
Update an access restriction. Same schema as for but fields such as |
|
|
The if the specified by any User or Group. The existing and Groups must be removed before they can be deleted. |
|
|
Return Values for Access Restriction
These are the return values for the Access Restriction methods:
Property | Method | Description | Required |
|---|---|---|---|
|
| URI of access restriction | Yes |
|
| User assigned name of the access restriction |
|
|
| User assigned description of the access restriction | No |
|
| Array of ip addresses or CIDR blocks | Yes |
|
| The types of API access methods that are excluded from access restriction enforcement | No |
Trusted Proxy IPs
When a client is connected to the PCE's haproxy server, this connection can traverse one or more load balancers or proxies. Therefore, the source IP address of a client connection to haproxy might not be the actual public IP address of the client.
Proxies and intermediaries often use the X-Forwarded-For header (and some other custom headers, like X-Client-IP) to pass along the client IP address. The value of this header is a comma-separated list of one or more IP addresses, where the source IP address seen by the most recent proxy is at the end of the list.
The client IP address used for API requests and Web UI connections comes from the value of the X-Forwarded-For header that haproxy sets on the back-end request to the web service. It is set to one of these values:
Value of the
X-Forwarded-Forheader on the incoming request (whentrust_upstream_x_forwarded_foristrue)Source IP address of the client connection to haproxy (when
trust_upstream_x_forwarded_forisfalse)
Configurable trusted proxy IPs allow Org Owners to configure a list of IPv4 addresses or CIDR blocks that are considered trusted for setting a client's X-Forwarded-For header.
The Org Owner can designate the trusted proxies/intermediaries using this setting. The PCE will consider all others to be untrusted when setting the X-Forwarded-For header.
The haproxy is configured to always put the client's source IP address in the X-Real-IP header on the back-end request and to pass along any X-Forwarded-For headers in the front-end request.
Trusted Proxy IP Methods
Functionality | HTTP | URI |
|---|---|---|
Get a list of trusted IP proxies |
|
|
Inter-service API for fetching an orgs' It uses the same schema as the GET endpoint above; it receives the org_id as a query input |
|
|
Update with the same schema as the GET endpoint (except without the property)
|
|
|
Trusted Proxy IPs
These are the return values for the Trusted Proxy methods:
Parameter | Method | Description | Req |
|---|---|---|---|
|
| Maximum number of Trusted Proxy IPs allowed for each PCE | Yes |
|
| Required:
| Yes |
Organization Access
Changes to the organization access introduced a new common schema:
common ipv4_ipv6_subnet
This common schema is replacing the one that is now deleted: common ipv4_subnet
{
"$schema": "http://json-schema.org/draft-04/schema#",
"type": "string",
"pattern": "^((25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\\.)
{3}(25[0-5]|2[0-4][0-9]|[01]?[0-9]
[0-9]?)(\\/(3[0-2]|[0-2]?[0-9]))?$"
}Three organization access APIs have been changed to substitute common/ipv4_subnet.schema with common/ipv4_ipv6_subnet.schema:
orgs_access_restrictions_postorgs_access_restrictions_put