splunk-operator

Secure Splunk deployments in Kubernetes

Before creating new deployments in Kubernetes, it is important you consider the security aspects of your environment. This document describes how to secure your deployment using the Operator and Splunk Enterprise configurations, and provides examples for some common scenarios.

Splunk Enterprise provides a range of security frameworks that are also available in your Kubernetes deployment. Take the time to familiarize yourself with these frameworks in the Securing the Splunk Platform manual.

Your deployment might require communication with Splunk Enterprise instances running outside of Kubernetes. For example, forwarders outside of the Kubernetes cluster sending data into an Indexer Cluster running in Kubernetes. This can be done using a Ingress Controllers such as Istio, Nginx, among others. In this documentation we use Istio for our examples.

The procedures to secure your deployment are the same regardless of your choice for Ingress Controller. See the table below for the ingress communications supported by the Operator:

Supported communications from outside of the cluster

Outside Kubernetes SSL/TLS Configuration Supported
Forwarders Gateway Termination YES
Forwarders End-to-End Termination YES
Splunk Web End-to-End Termination YES
REST API End-to-End Termination YES
Splunk Web Gateway Termination NO
REST API Gateway Termination NO

For more information about how to setup Ingress Controllers using the Operator visit Ingress Documentation.

Prerequisites

Learn about securing communication channels

Use SSL/TLS certificates to secure the communication between Splunk platform instances. See Secure Splunk with SSL.

Prepare your Certificates

For information on how to create your own certificates or how to sign third-party certificates, see: How to Sign Certificates

Securing Splunk Web using Certificates

In this example, the certificates and configuration files are placed into one app and deployed to a standalone Splunk Enterprise instance, and the Kubernetes Ingress controller is configured to allow inbound communications on port 8000 (Splunk Web.)

myapp
├── default
│   ├── app.conf
│   └── web.conf
└── mycerts
    ├── mySplunkCertificate.pem
    └── mySplunkPrivateKey.key

Sample app.conf

[install]
is_configured = 0

[ui]
is_visible = 1
label = MyApp

[launcher]
author = Splunk
description = My Splunk App
version = 1.0

Sample web.conf

[settings]
enableSplunkWebSSL = true
privKeyPath = $SPLUNK_HOME/etc/apps/myapp/mycerts/mySplunkPrivateKey.key
serverCert =  $SPLUNK_HOME/etc/apps/myapp/mycerts/mySplunkCertificate.pem
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: splunk-web
spec:
  selector:
    istio: ingressgateway # use istio default ingress gateway
  servers:
  - port:
      number: 8000
      name: ui
      protocol: TCP
    hosts:
    - "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: splunk-web
spec:
  hosts:
  - "splunk.example.com"
  gateways:
  - "splunk-web"
  tcp:
  - match:
    - port: 8000
    route:
    - destination:
        host: splunk-standalone-standalone-service
        port:
          number: 8000
kubectl patch -n istio-system service istio-ingressgateway --patch '{"spec":{"ports":[{"name":"splunk-web","port":8000,"protocol":"TCP"}]}}'

Securing Rest APIs

In this example, the certificates and configuration files are placed into one app and deployed to a standalone Splunk Enterprise instance, and the Kubernetes Ingress controller is configured to allow inbound communications on port 8089 (Splunk Management.) The method to secure communications for REST API access is similar to the Splunk Web example above.

myapp
├── default
│   ├── app.conf
│   └── server.conf
└── mycerts
    ├── mySplunkCertificate.pem
    └── mySplunkPrivateKey.key

Sample app.conf

[install]
is_configured = 0

[ui]
is_visible = 1
label = MyCertificatesApp

[launcher]
author = Splunk
description = My Splunk App for Custom Configuration
version = 1.0

Sample server.conf

[sslConfig]
sslVersions = *,-ssl2
serverCert = $SPLUNK_HOME/etc/apps/myapp/mycerts/mySplunkAWSCertificate.pem
sslRootCAPath = $SPLUNK_HOME/etc/apps/myapp/mycerts/myCACertificate.pem
sslPassword = <password>
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: splunk-api
spec:
  selector:
    istio: ingressgateway # use istio default ingress gateway
  servers:
  - port:
      number: 8089
      name: mgmt
      protocol: TCP
    hosts:
    - "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: splunk-api
spec:
  hosts:
  - "splunk.example.com"
  gateways:
  - "splunk-api"
  tcp:
  - match:
    - port: 8089
    route:
    - destination:
        port:
          number: 8089
        host: splunk-standalone-standalone-service
kubectl patch -n istio-system service istio-ingressgateway --patch '{"spec":{"ports":[{"name":"splunk-api","port":8089,"protocol":"TCP"}]}}'
curl --cacert <PathTomyCACertificate.pem> -s -u admin -L "https://<domain:8089>/<api>"

Note: You can avoid entering your password in the curl command by using a sessionKey. To learn more about the different forms of authentication, see: REST Authentication methods

Learn more about APIs available here: REST Manual

Securing Forwarders

For examples on configuring the Ingress controller to accept data from Forwarders, and securing the data in Kubernetes, see: Secure Forwarding

Password Management

In Kubernetes, sensitive information such as passwords, OAuth tokens, and ssh keys should be stored using the Secrets objects. Learn how to manage your passwords for Splunk Enterprise deployments in: Password Management