Access control

Two independent questions govern who sees what:

1. Can this Splunk user run the commands at all? Answered by Splunk roles and capabilities.
2. Whose AWS permissions does the search run under? Answered by the credential each account resolves to for that user.

Get both right and Search for AWS gives analysts controlled, audited read access to AWS without handing out console logins or access keys.

Splunk roles and capabilities

The app defines two capabilities:

And two roles that bundle them:

These are the names Splunk shows under Settings - Roles; in authorize.conf the stanzas are [role_aws_search_user] and [role_aws_search_admin]. A full Splunk administrator (admin_all_objects, or sc_admin on Splunk Cloud) can do everything without an explicit role. Note that aws_search_user does not get list_storage_passwords: the search commands resolve their credential through a system-context handler, so users run searches without being able to read the credential store directly. The dashboards read no secrets either; they run the same commands.

The two capabilities are independent. Grant edit_aws_search_accounts on its own, through a role you create, to someone who keeps the AWS credentials without being allowed to query AWS with them: they can do everything in that row of the table from the Setup page, and cannot run a search or keep a per-user credential. Such a role does not have to inherit from user or carry any of Splunk’s administrative capabilities - the app checks the capability and then saves with its own permissions.

Credential models

Each account resolves to one of two credentials for a given user. They differ in whose AWS identity a search runs under and in how well one user is isolated from another.

Shared account credential

The credential on the account form. Every user’s searches use it unless they have an override. Simplest to set up and the only model on the free tier.

A shared credential is usable by everyone who can search. The app hands a shared credential only to a running search of the caller’s own - a bare | rest against the credential endpoint no longer returns it - but that stops a passing look, not a determined one: any Splunk user with run_aws_search can still arrange to read a shared static key through a search and use it outside Splunk with its full IAM permissions. Treat it as readable by every searcher, and scope it to least privilege accordingly - the read-only policy in Accounts, nothing broader. With an assumed role the base key is likewise reachable, with whatever IAM permissions the base identity holds - so give that identity sts:AssumeRole on the one role and nothing else. Used outside Splunk it can open sessions under any session name, so the Splunk username in CloudTrail identifies searches made through the app, not every use of the key.

Per-user credentials

A user registers their own credential for an account on the Credentials tab - their own access keys, or their own role to assume - and their searches use it instead of the shared one. The override’s settings live in the user’s own awsauth.conf and its secrets in the app’s credential store under a name bound to that user, which the app resolves for that user only, so people query with their own IAM permissions and one user cannot borrow another’s. A user can still extract their own key (it is theirs), but not anyone else’s. A per-user role carries its own base credentials (the user’s static keys that make the sts:AssumeRole call), and cannot be saved without them. Per-user credentials require a paid license.

An override has to be a credential of the user’s own. Saving one with auth_type = instance_role, or an assumed role with no base key pair, is refused: both would sign requests with the search head’s own identity rather than the user’s, and an override replaces the account’s credential outright. A stanza of either shape already in a user’s awsauth.conf is ignored, the account’s own credential is used instead, and the search says so in its messages. An account an administrator configured that way is unaffected.

Choosing

As a rule: shared with a read-only identity for an account everyone may see equally, per-user when people genuinely have different IAM permissions and each search should reflect the searcher’s own access.

Attribution in CloudTrail

An assumed-role session opened by the app carries a role session name of os_aws_search@<splunk-user>, and every request the app makes carries a user agent that begins with os_aws_search/<version>. The target account’s CloudTrail therefore shows which person ran a search, not just that the search head did - the userIdentity.sessionContext names the session, and userAgent names the app. (The describe and list calls the Cloud Control API makes on the app’s behalf for | awsget are the exception: those events carry Cloud Control’s agent, under the same session.) A user cannot spoof this: the session name on a per-user override is always the authenticated Splunk user’s, whatever the override says.

One setting turns it off. A shared account has an optional role session name field, and a name set there is used for every user’s session on that account, coerced to AWS’s session-name character set. Leave it empty if you want per-person attribution; static keys and the instance role carry no session name at all, so there the user agent is the only mark.

Auditing usage

Because Search for AWS gives live read access to your accounts, you will want to see who ran what. There are two trails.

In Splunk. Every search is recorded in the audit index, with the user and the SPL they ran:

index=_audit action=search
| search search="*| awsget*" OR search="*| awslogs*" OR search="*| awsmetrics*" OR search="*| awscloudtrail*" OR search="*| awscost*" OR search="*| awsathena*" OR search="*| awsglue*" OR search="*| awstag*"
| table _time user search

In AWS. Every call the app makes is a CloudTrail event in the account it reached, with the user agent and, for assumed roles, the per-user session name above. Search for AWS can read that trail itself:

| awscloudtrail attribute=Username value=os_aws_search@alice start=-7d region=us-east-1
| stats count by event_source event_name