Hi guys
What are the fewest number of Splunk capabilities I need to assign to a user role to send data into an index (via SPLK API POST request)?
Use-case - I have an app configured to send data to Splunk via the REST API, using a Splunk user account to authenticate. For security I want to limit the number of capabilities this account has, so that it can only be used to post data into an index (assigning sourcetype, source, index in the request).
Thanks!
All you need is edit_tcp
, nothing else.
Be wary though, giving someone that capability will inevitably allow them to - duh - edit TCP inputs.
$ curl -ku post:snip "https://localhost:8089/services/receivers/simple?index=main&host=test&source=test&sourcetype=test" -d "testdata"
<?xml version="1.0" encoding="UTF-8"?>
<response>
...successful stuff here, event does appear in main...
</response>
$ curl -ku post:snip "https://localhost:8089/services/data/inputs/tcp/raw" -d "name=12345"
<?xml version="1.0" encoding="UTF-8"?>
<response>
<messages>
<msg type="ERROR">In handler 'raw': You do not have permission to access capability list_inputs</msg>
</messages>
</response>
That gives me an error, however the input was created... it's just the lack of capability for listing the input I just created that produces the error. Using this capability you can create lots of mayhem... but then you can create arbitrary events that look like the real thing, so there's lots of possibilities there for abuse already.
Here's my config:
authorize.conf
[role_user-post]
edit_tcp = enabled
passwd
:post:<snip>:::user-post:::
inputs.conf
[tcp://12345]
# this wasn't here before...
Any ideas of how this needs to be adjusted for Splunk Cloud where edit_tcp is not allowed? I've got a case where something is working under a role with sc_admin capabilities but I don't want the role is should really run under to have everything that is capable of. Documentation is sparse
All you need is edit_tcp
, nothing else.
Be wary though, giving someone that capability will inevitably allow them to - duh - edit TCP inputs.
$ curl -ku post:snip "https://localhost:8089/services/receivers/simple?index=main&host=test&source=test&sourcetype=test" -d "testdata"
<?xml version="1.0" encoding="UTF-8"?>
<response>
...successful stuff here, event does appear in main...
</response>
$ curl -ku post:snip "https://localhost:8089/services/data/inputs/tcp/raw" -d "name=12345"
<?xml version="1.0" encoding="UTF-8"?>
<response>
<messages>
<msg type="ERROR">In handler 'raw': You do not have permission to access capability list_inputs</msg>
</messages>
</response>
That gives me an error, however the input was created... it's just the lack of capability for listing the input I just created that produces the error. Using this capability you can create lots of mayhem... but then you can create arbitrary events that look like the real thing, so there's lots of possibilities there for abuse already.
Here's my config:
authorize.conf
[role_user-post]
edit_tcp = enabled
passwd
:post:<snip>:::user-post:::
inputs.conf
[tcp://12345]
# this wasn't here before...