Splunk Cloud Self-Service: Announcing The New Admin Config Service API

Share:

By Christian Roth January 15, 2021

In our last blog, 'What's New in Splunk Cloud: Part 1,' we reviewed a host of new Splunk Cloud features that we have delivered through our accelerated releases since the beginning of 2020. A large part of this effort focused on empowering Splunk Cloud admins and making their experience as self-service as possible. In this blog, we will examine our latest effort to continue this empowerment: Splunk Cloud's Admin Configuration Service (ACS).

Today's infrastructure exists in a dynamic and rapidly changing environment. New compute sources and networks come online quickly, and Splunk Cloud admins have to keep pace to ensure that this data flows into their Splunk Cloud deployment. Traditional IP allow lists can be leveraged to permit one or more IP addresses from accessing Splunk. However, the ACS API enables admins to quickly add or remove IPs or entire subnets from their Splunk environments.

The ACS API was purposefully built for Splunk Cloud admins who require self-service management of their Splunk deployments. As such, the API is equipped with a rich set of features that extend well beyond the user interface. Starting with IP allow lists, ACS is a RESTful API that equips Splunk Cloud admins with a steady stream of capabilities (private app management, HEC tokens) that will remove friction and provide full control over their deployments. Moreover, the good news is that ACS is available now across all 8.x Splunk Cloud environments, so customers in these environments can begin using ACS right away.

Let's take a closer look at allow listing. ACS streamlines a number of common IP allow list use cases.

Table 1.0 - Use Cases

Use Case	Splunk Resource
API access	Search Head
HEC-based ingestion	Indexer
Forwarder-based ingestion	Indexer
UI access (if applicable)	Search Head
UI access (if applicable)	Inputs Data Manager
IDM API access	Inputs Data Manager

Now, let's dig into the API itself.

Getting Started

ACS can be leveraged by Curl or any equivalent API client. For the examples below, we will leverage the Postman API client.

The first call to ACS will be to retrieve the OpenAPI 3.0 specification. This information will provide a comprehensive description of the REST APIs.

Using Postman, we can perform a simple Get call to the ACS endpoint at https://admin.splunk.com.

We now have all of the required parameters, meta-data, and other relevant information we need to make subsequent requests.

Now that we have the API specifications, we need an authentication token to grant our admins access to use ACS. Currently, ACS leverages JSON Web Token (JWT) support. A Splunk JWT will need to be presented in all ACS requests. The lifespan of the JWT can vary-ranging anywhere from a few minutes to 60 days. Any customer using Splunk version 8.0.2007 or higher can create and distribute these credentials.

Please consult the Splunk documentation for more information on setting up and managing tokens in your environment.

Using the API

Now that we've covered setup, let's start using the API. To make our life easier, we have assigned our Splunk deployment details to specific variables like stack, baseURL, and feature (HEC, S2S, Search-API). Keep in mind that feature can include any of the predefined IP allow list blocks (see ACS documentation for the full set of feature types). Finally, we have assigned our Splunk JWT to a token variable and passed this value in our authorization header.

A simple Get call will provide a listing of all subnets for that feature type. For example, I can request all of my in-use subnets for HEC or Splunk forwarding (S2S). For more information, please see the documentaton for Splunk Cloud Admin Guide: Configure IP Allow lists.

Easy enough so far? Ok, let's add some new subnets to our Splunk deployment. ACS can accept one or more subnets in JSON format (see image below). Although the URI is the same, it's good practice to check the feature type before any submissions, especially if the feature is assigned to a variable in Postman. Please note that the first octet was replaced with a '#' here. ACS expects subnets to be expressed in standard CIDR notation.

Note that a 200 response code indicates that the request has successfully passed all ACS validation (e.g., the public IP is valid and not on the Bogon list) and is in the queue to be applied to your Splunk deployment. The time between a submission and update to your deployment is typically within a few minutes.

While not necessary, you can query the status of the change set. For the sake of completeness, let's go through that exercise. We would simply make the following call by passing only your Splunk deployment (stack) name.

ACS will respond with one of three responses:

• Ready - all changes have been applied to your deployment
• Pending -there are some changes that have not been applied to your deployment
• Failed - the changes failed in your deployment. Please contact Splunk Support to open a case if you encounter successive failures.
  

Rounding out ACS's initial launch features is support for removing allow lists. The delete request mirrors the format of the POST (add subnet allow list) call.

Wrapping Up

As you can see, leveraging the ACS API is a simple and easy approach to directly manage your Splunk Cloud deployment. For more information, please consult the following reference:

• Splunk Cloud Admin Guide: Configure IP Allow lists
  

Keep your eyes on this space for additional announcements and new capabilities geared toward Splunk Cloud admins.