You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This section will cover various security considerations when using the Splunk Enterprise and Universal Forwarder containers.
3
+
4
+
### Startup Users ###
5
+
6
+
The Splunk Enterprise and Universal Forwarder containers may be started using one of the following three user accounts:
7
+
8
+
*`splunk` (most secure): This user has no privileged access and cannot use `sudo` to change to another user account.
9
+
It is a member of the `ansible` group, which enables it to run the embedded playbooks at startup. When using the
10
+
`splunk` user, all processes will run as this user. Note that you must set the `SPLUNK_HOME_OWNERSHIP_ENFORCEMENT`
11
+
environment variable to `false` when starting as this user. ***Recommended for production***
12
+
13
+
*`ansible` (middle ground): This user is a member of the `sudo` group and able to execute `sudo` commands without a
14
+
password. It uses privileged access at startup only to perform certain actions which cannot be performed by regular
15
+
users (see below). After startup, `sudo` access will automatically be removed from the `ansible` user if the
16
+
environment variable `STEPDOWN_ANSIBLE_USER` is set to `true`. ***This is the default user account***
17
+
18
+
*`root` (least secure): This is a privileged user running with UID of `0`. Some customers may want to use this for
19
+
forwarder processes that require access to log files which cannot be read by any other user. ***This is not recommended***
20
+
21
+
### After Startup ###
22
+
23
+
By default, the primary Splunk processes will always run as the unprivileged user and group `splunk`,
24
+
irregardless of which user account the containers are started with. You can override this by changing the following:
25
+
26
+
* User: `splunk.user` variable in your `default.yml` template, or the `SPLUNK_USER` environment variable
27
+
* Group: `splunk.group` variable in your `default.yml` template, or the `SPLUNK_GROUP` environment variable
28
+
29
+
Note that the containers are built with the `splunk` user having UID `41812` and the `splunk` group having GID `41812`.
30
+
31
+
You may want to override these settings to ensure that Splunk forwarder processes have access to read your log files.
32
+
For example, you can ensure that all processes run as `root` by starting as the `root` user with the environment
33
+
variable `SPLUNK_USER` also set to `root` (this is not recommended).
34
+
35
+
### Privileged Features ###
36
+
37
+
Certain features supported by the Splunk Enterprise and Universal Forwarder containers require that they are started
38
+
with privileged access using either the `ansible` or `root` user accounts.
39
+
40
+
#### Splunk Home Ownership ####
41
+
42
+
By default, at startup the containers will ensure that all files located under the `SPLUNK_HOME` directory
43
+
(`/opt/splunk`) are owned by user `splunk` and group `splunk`. This helps to ensure that the Splunk processes are
44
+
able to read and write any external volumes mounted for `/opt/splunk/etc` and `/opt/splunk/var`. While all supported
45
+
versions of the docker engine will automatically set proper ownership for these volumes, external orchestration systems
46
+
typically will require extra steps.
47
+
48
+
If you know that this step is unnecessary, you can disable it by setting the `SPLUNK_HOME_OWNERSHIP_ENFORCEMENT`
49
+
environment variable to `false`. Note that this must be disabled when starting containers with the `splunk` user
50
+
account.
51
+
52
+
#### Package Installation ####
53
+
54
+
The `JAVA_VERSION` environment variable can be used to automatically install OpenJDK at startup time. This feature
55
+
requires starting as a privileged user account.
56
+
57
+
### Kubernetes Users ###
58
+
59
+
For Kubernetes, we recommend using the `fsGroup`[Security Context](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/)
60
+
to ensure that all Pods are able to write to your Persistent Volumes. For example:
61
+
62
+
```
63
+
apiVersion: v1
64
+
kind: Pod
65
+
metadata:
66
+
name: example-splunk-pod
67
+
spec:
68
+
securityContext:
69
+
runAsUser: 41812
70
+
fsGroup: 41812
71
+
containers:
72
+
name: example-splunk-container
73
+
image: splunk/splunk
74
+
env:
75
+
- name: SPLUNK_HOME_OWNERSHIP_ENFORCEMENT
76
+
value: "false"
77
+
...
78
+
```
79
+
80
+
This can be used to create a Splunk Enterprise Pod running as the unprivileged `splunk` user which is able to securely
81
+
read and write from any Persistent Volumes that are created for it.
82
+
83
+
Red Hat OpenShift users can leverage the built-in `nonroot`[Security Context Constraint](https://docs.openshift.com/container-platform/3.9/admin_guide/manage_scc.html)
# Container Artifact Directory is a place for all artifacts and logs that are generated by the provisioning process. The directory is owned by the user "ansible".
0 commit comments