Configure IP allow lists for Splunk Cloud Platform

Splunk Cloud Platform IP allow lists control which IP addresses on your network have access to specified components (features) in your Splunk Cloud Platform deployment. You can use the Admin Config Service (ACS) API to add or remove subnets from the allow list and manage access to features in your Splunk Cloud Platform environment programmatically.

The Terraform Provider for Splunk Cloud Platform now supports ACS IP allow list operations. To access the Splunk Cloud Platform Terraform Provider (terraform-provider-scp), see the Terraform Registry.

Requirements

To configure IP allow lists using the ACS API:

• Your role must have the capabilities required to access the ACS API endpoint. The sc_admin role has all required capabilities by default. For a list of required capabilities, see Manage ACS API access with capabilities.
• You must have Splunk Cloud Platform version 8.0.2007 or higher.
• Your deployment must have one or more separate search heads or a search head cluster. ACS is not supported on single instance deployments.
• Configuring IP allow lists on premium search heads requires search head targeting. For more information, see Target a specific search head for ACS operations.

ACS does not support IP allow list management on FedRAMP High environments. To modify the allow list you must contact Splunk Support.

ACS IP allow lists support IPV4 addresses only

Set up the ACS API

Before using the ACS API, you must download the ACS Open API 3.0 specification, which includes the parameters, codes, and other data you need to work with the ACS API.

You must also create a JWT authentication token in Splunk Cloud Platform for use with ACS endpoint requests. You can create this token manually in the Splunk Web UI or programmatically using the ACS API.

For details on how to retrieve the ACS Open API spec and create an authentication token, see Set up the ACS API.

Determine IP allow list use case

The ACS API supports several common IP allow list use cases. In each use case, the IP allow list controls access to a particular Splunk Cloud Platform feature. When you send a request to the ACS endpoint, you must specify the {feature} argument, such as search-api, hec, s2s, and so on. Note that the value of {feature} refers to a logical grouping of subnets that are granted access to a Splunk component.

The ACS API supports the following IP allow list use cases:

Use Case	Feature	Port	Description
Search head API access	search-api	8089	Grants access for customer subnets to Splunk search head api (applies to automated interfaces)
HEC access for ingestion	hec	443	Allows customer's environment to send HTTP data to Splunk indexers.
Indexer ingestion	s2s	9997	Allows subnets that include UF or HF to send data to Splunk indexers.
SH UI access	search-ui	80/443	Grant explicit access to search head UI in regulated customer environments.
IDM UI access	idm-ui	443	Grant explicit access to IDM UI in regulated customer environments.
IDM API	idm-api	8089	Grant access for add-ons that require an API. (Allows add-ons to send data to Splunk Cloud Platform.)

IP allow list rules apply to the entire Splunk Cloud Platform deployment stack, not just to individual components. For example, any subnet that you add to the search-api feature allow list will have access to the entire search head tier, including all individual search heads and search head clusters. Likewise, any forwarder whose subnet you add to the s2s feature allow list will have access to all indexers.

IP allow list behavior and IP subnet limits

IP allow lists for ACS features are open by default to all IP addresses (set to 0.0.0.0/0), with the exception of search-api, which are closed by default, and search-ui which is closed by default on PCI and HIPAA compliance stacks, but open by default otherwise.

For allow lists that are open by default, to restrict access to a specific range of IP addresses, you must explicitly add the IP subnet range to the allow list. For allow lists that are closed by default, you must explicitly add the range of IP addresses to which you want to grant access. Once you add an IP subnet range, only those IPs added to the allow list have access to the feature.

If you subsequently add additional subnets to the allow list, ACS appends those IP subnet ranges to the existing IP subnet ranges. ACS does not overwrite existing IP subnets on the allow list.

The default IP allow list configuration is not initially visible when performing a GET request to describe an allow list. The allow list configuration is only visible after you add subnets to the allow list.

How IP subnet limits work

ACS enforces limits on the total number of IP subnets you can add to your IP allow lists. For deployments on AWS, IP subnet limits apply to IP allow list groups for search head, indexer, and IDM tiers, as well as single instances. While a feature maps to a single IP allowlist, a group can map to multiple IP allowlists.

There is a total limit of 230 subnets per IP allow list group. This limit applies to the allow lists for all features across the allow list group. For example, you can add a maximum of 230 subnets to the Indexer group, which includes the allow lists for the hec and s2s features.

The table shows IP subnet limits per IP allow list group for deployments on AWS:

IP allow list group	ACS features	IP subnet limit
Search head	search-api, search-ui	230
Indexer	hec, s2s	230
IDM	idm-api, idm-ui	230
Single Instance	search-api, search-ui, hec, s2s	230

Note that ACS enforces a 200 IP subnet limit for each individual ACS feature allow list, while the total subnet limit of 230 is shared between all feature allow lists in an IP allow list group. The table shows some valid and invalid subnet limit scenarios for the Indexer group: :

hec allow list	s2s allow list	Total subnets	Valid/Invalid
200	30	<= 230	Valid
150	80	<= 230	Valid
150	150	>= 230	Invalid. IP allow list group exceeds 230 subnet limit.
210	20	<= 230	Invalid. hec feature allow list exceeds 200 subnet limit.

For deployments on GCP, you can add a maximum of 200 IP subnets to the IP allow list for each ACS feature.

Configure IP allow lists

The following sections show you how to update and manage IP allow lists in Splunk Cloud Platform using the ACS API.

View current IP allow lists

To view the full list of existing subnets for a particular IP allow list feature type, send an HTTP GET request to the following endpoint:

admin.splunk.com/{stack}/adminconfig/v2/access/{feature}/ipallowlists

For example, to view the full list of subnets for the s2s IP allow list feature type, send the following request:

curl https://admin.splunk.com/{stack}/adminconfig/v2/access/s2s/ipallowlists \
--header 'Authorization: Bearer eyJraWQiOiJzcGx1bmsuc2...'

The request returns the current allow list subnets for the s2s feature type only. For example:

{
  "subnets": [
     ": #.0.0.0/24",
     ": #.0.0.0/24",
     ": #.0.10.6/32"
  ]
}

To view the current allow list subnets for a different feature, you must specify that feature type in the request. See Determine IP allow list use case.

For ACS IP allow list endpoint details, see access/{feature}/ipallowlist in the ACS API endpoint reference.

Add subnets to IP allow list

To add a new subnet to the IP allow list:

Send an HTTP POST request to the access/{feature}/ipallowlists endpoint, specifying the subnet that you want to add. For example, to add new subnets to the IP allow list for the s2s feature:

curl -X POST 'https://admin.splunk.com/mystack/adminconfig/v2/access/s2s/ipallowlists' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer eyJraWQiOiJzcGx1bmsuc2VjcmV0Iiw...' \
--data '{
"subnets": [
"###.0.0.0/24",
"##.0.10.6/32"
]
}'

A 200 response code indicates that your request was submitted successfully.

It can take several minutes for the subnet update to be applied to your Splunk Cloud Platform stack.

To check the status of your subnet update request, send an HTTP GET request specifying the {stack} value (URL prefix of your Splunk Cloud Platform deployment) as the only argument. For example:

curl https://admin.splunk.com/{stack}/adminconfig/v2/status \
--header 'Authorization: Bearer eyJraWQiOiJzcGx1bmsuc2...'

ACS returns one of the following status responses:

• Ready: The environment is ready, and infrastructure is up to date.
• Pending: The stack has some pending changes that haven't been applied to the environment yet. The changes could be internal system changes for the environment or user requested changes like a modification to allow lists.
• Failed: There were some errors while applying changes to the environment. The changes could be internal system changes for environments or user requested changes like a modification to allow lists. If you continue to experience errors, contact Splunk Support.

Remove subnets from IP allow list

To remove a subnet from an IP allow list:

Send an HTTP DELETE request specifying the subnet you want to delete. For example, to remove subnets from the IP allow list for the s2s feature:

curl -X DELETE 'https://admin.splunk.com/mystack/adminconfig/v2/access/s2s/ipallowlists' \
--header 'Authorization: Bearer eyJraWQiOiJzcGx1bmsuc2Vj...' \
--header 'Content-Type: application/json' \
--data '{
"subnets": [
"###.0.0.0/24",
"##.0.10.6/32"
]
}'

For ACS IP allow list endpoint details, see access/{feature}/ipallowlist in the ACS API endpoint reference.

Confirm IP allow list update

To verify that your IP allow list has been updated as expected by POST or DELETE requests:

Send an HTTP GET request specifying the {stack} value (URL prefix of your Splunk Cloud Platform deployment) as follows:

curl https://admin.splunk.com/mystack/adminconfig/v2/status\
--header 'Authorization: Bearer eyJraWQiOiJzcGx1bmsuc2...'

Example: Allow a universal forwarder to send data to Splunk Cloud Platform indexers

To allow a Splunk universal forwarder on your network to send data to indexers in your Splunk Cloud Platform deployment, you must add the IP subnet that contains the forwarder's IP address to the correct IP allow list in Splunk Cloud Platform.

1. Create an authentication token in Splunk Cloud Platform for use with the ACS API. See Generate an authentication token.
2. Determine the IP subnet that contains your forwarder. For example:

   122.0.0.0/24
   

3. Determine the feature type of the IP allow list to which you must add the forwarder's subnet. In this example, you want to allow Splunk Cloud Platform indexers to ingest data from an external forwarder, so the use case is indexer ingestion and the corresponding IP allow list feature type is s2s. See Determine IP allow list use case.
4. Send a POST request to add the new subnet to the s2s IP allow list.

   curl -X POST 'https://admin.splunk.com/mystack/adminconfig/v2/access/s2s/ipallowlists' \
   --header 'Content-Type: application/json' \
   --header 'Authorization: Bearer eyJraWQiOiJzcGx1bmsuc2VjcmV0Iiw...' \
   --data '{
   "subnets": [
   "122.0.0.0/24"
   ]
   }'
   

5. Send a GET request to confirm that the updated s2s IP allow list now includes the forwarder's subnet. For example:

   curl https://admin.splunk.com/mystack/adminconfig/v2/access/s2s/ipallowlists
   

   The response shows the s2s IP allow list includes the forwarder's subnet:

   {
     "subnets": [
        ": 122.0.0.0/24",
        ": 50.0.10.6/32"
     ]
   }
   

For ACS IP allow list endpoint details, see access/{feature}/ipallowlist in the ACS API endpoint reference.