|
| 1 | +## Security ## |
| 2 | +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) |
| 84 | +to run Pods with the above Security Context: |
| 85 | +``` |
| 86 | +oc adm policy add-scc-to-user nonroot default |
| 87 | +``` |
0 commit comments