Nextpart Splunk Usergroup 04/2022

1. SPLUNK
USER
GROUP
Copyright © 2022 NEXTPART Security Intelligence GmbH. and / or affiliates. All rights reserved.
All data is notional and not subject to confidentiality provisions.
› 2022 Q2
DevOps Perspective

2. ... crafts innovative technologies and provides professional services
with consulting in the areas of information security, optimization of
defense operations and protection of corporate IT infrastructure.
MICHAEL BISCHOF
• Red Bull seit 2016
• FH-Hagenberg
Sichere Informationssysteme & Information Security Management
• NEXTPART seit 2019 (CEO & Co-Founder)

3. Retrospektive
Wir haben nach effizienteren und effektiveren Wegen gesucht!
›
� Wie arbeiten wir mit Splunk?
� Was tun wir dabei eigentlich?
� Wo arbeiten wir und wo liegen unsere Assets?
� Welche Tools setzen wir dabei ein?

4. MOTIVATION
› modern DevOps workstyle
🏎️ Schnelle und einfache Entwickelung
(bzw. Testing)
🔁 Synchronisation von Instanzen
(User, Rollen, Indices, Inputs, etc.)
📦 Paketieren und “vetting” von Apps & Add-ons
(lokal & in CI-Pipelines)

5. Aspekte (/Prinzipien)
› Technologien im Einsatz
Mono-Repository
alle Apps, Add-ons, Config, etc. in
einem Repository
Github
Build & Validate
jede Komponente durchläuft die CI-
Pipeline und generiert Testreports
Azure DevOps
Central Storage
Zentral abgelegte Einstellungen,
Zugänge und Sample-Daten
Vault & Minio
Infrastructure as Code
Entwicklungsumgebung, Pipeline-Agents
und Testsysteme sind Container Images
Ansible &
Packer
Remote Development
Automatisierte & immutable Entwicklung
in der Cloud
Gitpod & K8s
API-First
Nutzung von Schnittstellen wo es nur
geht um Arbeit zu sparen
Splunk-SDK,
Splunkbase,
etc.

6. > docker run -it
-v "`pwd`/apps/APP_FOLDER_NAME:/apps/APP_FOLDER_NAME"
-v "`pwd`/dist:/dist"
-e "MYUSER=`id -u`"
nextpart/splunk-package:latest
Package & Validate Apps
Docker Image
― Python Package – Standard von Splunk selbst für lokales Vetting.
(kann zickig mit der Python-Version sein ... >= 3.9 ftw 🚀)
― Ansible Playbook – Installation des Packages und dem provisionieren
eines Entrypoint-Scripts für Clean-Up, Permissions, etc.
― Packer Build – Minimalistische Images ohne Ansible dependency im
container und einfach geil!
🔗https://github.com/nextpart/splunk-utilities

7. parameters:
- name: Applications
displayName: "Applications to process:"
type: object
default:
- SOCToolkit_nxtp
jobs:
- job: DetermineApps
steps:
# < insert pay-2-win magic here >
- ${{ each app in parameters.Applications }}:
- bash: |
docker run --rm
-v "$(Build.SourcesDirectory)/apps/${{ app }}:/apps/${{ app }}"
-v "$(Build.SourcesDirectory)/dist:/dist"
-e "MYUSER=$(id -u)" $(containerRegistry)/$(package_image)
- task: PublishTestResults@2
inputs:
testResultsFiles: "*.xml"
searchFolder: $(Build.SourcesDirectory)/dist/apps/${{ app }}
- task: PublishHtmlReport@1
inputs:
reportDir: "$(Build.SourcesDirectory)/dist/${{ app }}/Report.html“
- task: UniversalPackages@0
inputs:
publishDirectory: $(Build.SourcesDirectory)/dist/${{ app }}
vstsFeedPublish: $(artifact_feed)
# < insert more pay-2-win magic here >
validate_apps.azure-pipelines.yml
Alle Apps & Add-ons im
Mono-Repo (mit git-subrepos)
werden in einer Pipeline:
⎻ iterativ durchlaufen
⎻ vom Package-Image bereinigt,
packetiert und getestet
⎻ deren XML & HTML - Resultate
hochgeladen
⎻ als Artefakt in den Feed geladen

8. Resultate des “vetting”- Prozesses
werden in Azure DevOps im
JUNIT-XML
Format für Test-Plans
zum Tracking verwendet.
🔗 https://dev.azure.com/NEXTPART/_git/Splunking?path=/pipelines/github_apps.azure-pipelines.yml
Zusätzlich werden Beschreibung
und Resultate im
Releases
in einer Art “Report” mitgeliefert.
→ Die Ermittlung von Changes zwischen
Commits bzw. PRs reduziert die Anzahl.

9. All-in-one Tool
SDK & CLI 🔗https://github.com/nextpart/spl-manager
> spl docker start
1. Spin up a local development container:
> spl docker upload --path=“./apps” --app=“SOC*”
2. Put my local application(s) there:
> spl --src="onprem" samples --path="./apps/SA-Eventgen"
download --name=“SOC-Toolkit Application"
3. Get Eventgen sample data for an instance:
> spl docker download --app=“SOC*"
5. Download apps from development container to local folder:
4. Manipulate configs, searches, dashboards, etc.:
> spl apps --path=“./apps” --name=“SOC*” validate
6. Run AppInspect, Packaging & Cloud-Vetting:
> spl manager --conn=“onprem” users list
7. List various objects or perform operations on an instance:
> spl --src="onprem" --dest=“local“ sync users --create
8. Sync objects and their properties between instances:
> pip install spl-manager
0. Install the tool from python index (and configure it):

10. Entwicklungsumgebung
Ansible & K8s 🔗https://github.com/nextpart/splunk-workbench
Gitpod

11. Danke für euer Interesse!
Besonders an Christoph Siess für die geniale Zusammenarbeit.
Sowie das gesamte NTS-Team für die Location
und die Kooperation im gemeinsamen Projekt.
Und natürlich meine NEXTPART-Crew mit der wir jede Aufgabe meistern.