splunk-operator

Password Management

Global kubernetes secret object

A global kubernetes secret object acts as the source of secret tokens for a kubernetes namespace used by all Splunk Enterprise CR’s. It’s name follows the format splunk-<namespace>-secret where <namespace> represents the namespace we are operating in. The contents of this object are volume mounted on all the pods within a kubernetes namespace.

This approach:

Default behavior of global kubernetes secret object

Upon the creation of the first Splunk Enterprise CR in a given namespace, the operator checks for the existence of a global kubernetes secret object:

Note: Before the creation of any Splunk deployments in the kubernetes namespace, the admin can create a global kubernetes secret object using the tokens mentioned below. The operator will use these pre-populated values to deploy.

Splunk Secret Tokens in the global secret object

The configurable Splunk Secret Tokens include:

HEC Token

Key name in global kubernetes secret object: hec_token Description: hec_token is used to authenticate clients sending data into Splunk Enterprise via HTTP connections.

Default administrator password

Key name in global kubernetes secret object: password Description: password refers to the default administrator password for Splunk.

pass4Symmkey

Key name in global kubernetes secret object: pass4Symmkey Description: pass4Symmkey is an authentication token for inter-communication within Splunk Enterprise.

IDXC pass4Symmkey

Key name in global kubernetes secret object: idxc.secret Description: idxc.secret is an authentication token for inter-communication specifically for indexer clustering in Splunk Enterprise.

SHC pass4Symmkey

Key name in global kubernetes secret object: shc.secret Description: shc.secret is an authentication token for inter-communication specifically for search head clustering in Splunk Enterprise.

For examples of performing CRUD operations on the global secrets object, see examples. For more information on managing kubernetes secret objects refer kubernetes.io managing secrets

Information for Splunk Enterprise administrator

Secrets on Docker Splunk

When Splunk Enterprise is deployed on a docker container, ansible playbooks are used to setup Splunk. Ansible playbooks interpret the environment variable SPLUNK_DEFAULTS_URL in the container as the location to read the Splunk Secret Tokens from. The tokens are used to setup Splunk Instances running on containers inside pods.

SmartStore Access using AWS IAM Role for Service Account

Splunk 9.0.5 Supports Smartstore Access using AWS IAM Role for Service Account.

Below Example explains the steps required for setting up IAM Service Account

apiVersion: enterprise.splunk.com/v4
kind: Standalone
metadata:
  name: test
spec:
  serviceAccount: oidc-service-account
  smartstore:
    defaults:
        volumeName: test-cluster-bucket
    indexes:
      - name: main
        remotePath: $_index_name
        volumeName: test-cluster-bucket
      - name: cloudwatch
        remotePath: $_index_name
        volumeName: test-cluster-bucket
    volumes:
      - name: test-cluster-bucket
        path: test-cluster-bucket/smartstore
        endpoint: https://s3-us-west-2.amazonaws.com

OIDC key management The proper Key management of OIDC is outside of Splunk installation. The customer is responsible to use a properly configured OIDC using certificates from a trusted CA.

Self signed certificate The OIDC should not use self-signed certificates but rather utilize an existing PKI infrastructure, e.g. have the OIDC certificate issued and signed by your organization’s CA with proper certificate signature chains and key expiation policies.

Sharing OIDC token file Make sure the token file mentioned in AWS_WEB_IDENTITY_TOKEN_FILE location is only accessible inside of the pod and is not mapped or shared outside of the pod

Support for AWS IAM Role for Service Account in Splunk Operator Deployment

Follow the steps mentioned above for creating AWS IAM Service Account. Make sure IAM Role only has least amount of privilege necessary reading apps from S3 bucket. Once the service account is created, map this service account to splunk-operator deployment. Below is the example

apiVersion: apps/v1
kind: Deployment
metadata:
  name: splunk-operator-controller-manager
  namespace: splunk-operator
spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  ...
  spec:
    containers:
    -
      ...
      serviceAccount: oidc-service-account
      serviceAccountName: oidc-service-account
      terminationGracePeriodSeconds: 10
      volumes:
      - name: app-staging
        persistentVolumeClaim:
          claimName: splunk-operator-app-download
      ...