Security

Security Hardening Guide

Harden your DB Audit deployment for maximum security. This guide covers container security, TLS configuration, secrets management, network policies, and monitoring to ensure your audit infrastructure is as secure as the data it protects.

Container Hardening

All DB Audit containers should run with the most restrictive security context possible. The following Kubernetes securityContext configuration is recommended for all DB Audit pods.

# Kubernetes securityContext for DB Audit containers
securityContext:
  runAsNonRoot: true
  runAsUser: 1000
  runAsGroup: 1000
  readOnlyRootFilesystem: true
  allowPrivilegeEscalation: false
  capabilities:
    drop:
      - ALL
  seccompProfile:
    type: RuntimeDefault

Setting Explanations

runAsNonRoot: true

Prevents the container from running as root. Kubernetes will reject the pod if the container image attempts to run as UID 0.

runAsUser: 1000

Forces the container process to run as UID 1000, a non-privileged user. This limits the blast radius of any container escape.

runAsGroup: 1000

Sets the primary group to GID 1000. All file access is restricted to this group identity.

readOnlyRootFilesystem: true

Mounts the container root filesystem as read-only. Prevents attackers from writing malicious binaries or modifying configuration files inside the container.

allowPrivilegeEscalation: false

Prevents processes from gaining more privileges than their parent. Blocks exploits that rely on setuid binaries or kernel vulnerabilities.

capabilities.drop: ALL

Drops all Linux capabilities. DB Audit does not need any special kernel capabilities to function.

seccompProfile: RuntimeDefault

Applies the container runtime default seccomp profile, which blocks dangerous syscalls like mount, reboot, and ptrace.

Read-only root filesystem note

Since the root filesystem is read-only, DB Audit uses emptyDir volumes for temporary files. Mount an emptyDir at /tmp and /var/lib/dbaudit/cache to allow the collector to write temporary data and cache events locally.

TLS Configuration

All communication between DB Audit components must be encrypted with TLS. DB Audit enforces TLS 1.3 as the minimum version, providing the strongest available transport security.

Internal CA Setup

Use cert-manager or your organization's internal CA to issue certificates for DB Audit components. Short-lived certificates (90 days or less) are recommended to limit exposure from compromised keys.

mTLS Between Components

Enable mutual TLS between the collector, API server, and storage layer. Both client and server must present valid certificates, preventing unauthorized components from joining the cluster.

Certificate Rotation

Configure automatic certificate rotation using cert-manager or Vault PKI. DB Audit reloads certificates on-the-fly without requiring pod restarts, ensuring zero-downtime rotation.

Cipher Suites (TLS 1.3 Only)

DB Audit supports only TLS 1.3 cipher suites: TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, and TLS_AES_128_GCM_SHA256. All legacy cipher suites are disabled.

Helm Values for TLS

# Helm values for TLS configuration
tls:
  enabled: true
  certFile: /etc/dbaudit/certs/tls.crt
  keyFile: /etc/dbaudit/certs/tls.key
  caFile: /etc/dbaudit/certs/ca.crt
  minVersion: "1.3"

Secrets Management

DB Audit requires credentials for database connections, API keys, and TLS certificates. Proper secrets management is essential to prevent credential leakage and unauthorized access.

Kubernetes Secrets (Base Level)

The minimum acceptable approach. Store credentials in Kubernetes Secrets with RBAC restricted to only DB Audit service accounts. Enable encryption at rest for etcd. Note that base64 encoding is not encryption -- Kubernetes Secrets are only suitable when combined with etcd encryption and strict RBAC.

HashiCorp Vault Integration Recommended

Use the Vault Agent Injector to dynamically inject secrets into DB Audit pods at runtime. Secrets are never stored in Kubernetes, are automatically rotated, and access is fully audited. DB Audit supports dynamic database credentials via Vault's database secrets engine.

Sealed Secrets for GitOps

For GitOps workflows, use Bitnami Sealed Secrets to safely store encrypted secrets in Git. The SealedSecret controller in-cluster decrypts them into regular Kubernetes Secrets. This allows secrets to be version-controlled without exposing plaintext values.

Vault Agent Injector Example

# Vault agent injector annotations for DB Audit pods
annotations:
  vault.hashicorp.com/agent-inject: "true"
  vault.hashicorp.com/role: "dbaudit"
  vault.hashicorp.com/agent-inject-secret-db-creds: "secret/data/dbaudit/db-credentials"

Network Hardening

Apply Kubernetes NetworkPolicies to restrict traffic to and from DB Audit components. By default, Kubernetes allows all pod-to-pod communication -- NetworkPolicies enforce a zero-trust network model.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: dbaudit-collector
  namespace: dbaudit
spec:
  podSelector:
    matchLabels:
      app: dbaudit-collector
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: dbaudit-ui
      ports:
        - port: 8080
    - from:
        - namespaceSelector:
            matchLabels:
              name: monitoring
      ports:
        - port: 9090
  egress:
    - to:
        - ipBlock:
            cidr: 10.0.0.0/8
      ports:
        - port: 5432
        - port: 3306
        - port: 27017
        - port: 9000
        - port: 6379

Firewall Rules Summary

Direction	Source / Destination	Port	Purpose
INGRESS	dbaudit-ui pods	8080	UI to collector API
INGRESS	monitoring namespace	9090	Prometheus metrics scrape
EGRESS	10.0.0.0/8	5432	PostgreSQL audit log collection
EGRESS	10.0.0.0/8	3306	MySQL audit log collection
EGRESS	10.0.0.0/8	27017	MongoDB audit log collection
EGRESS	10.0.0.0/8	9000	ClickHouse audit log collection
EGRESS	10.0.0.0/8	6379	Redis audit log collection

RBAC Hardening

Apply least-privilege access controls at both the Kubernetes and DB Audit application layers. Restrict who can access what, and ensure all privileged actions are authenticated with strong credentials.

Minimal ServiceAccount

Disable automatic mounting of the Kubernetes API token. DB Audit collectors do not need access to the Kubernetes API, so the default token should never be mounted.

Enforce MFA for Admins

Require multi-factor authentication for all administrative accounts in DB Audit. MFA can be configured via TOTP, WebAuthn/FIDO2, or your identity provider's MFA enforcement.

Session Timeouts

Configure session timeouts based on role sensitivity. Recommended values: Admin: 30 minutes | Analyst: 8 hours | API tokens: no session (use short-lived JWTs)

IP Allowlisting

Restrict administrative access to known IP ranges. Configure the admin IP allowlist in DB Audit settings to block login attempts from unauthorized networks, even with valid credentials.

Minimal ServiceAccount Configuration

apiVersion: v1
kind: ServiceAccount
metadata:
  name: dbaudit-collector
  namespace: dbaudit
automountServiceAccountToken: false

Logging & Monitoring

DB Audit itself must be monitored for security events. Forward administrative audit logs to your SIEM, configure alerting for suspicious activity, and ensure log integrity with append-only storage.

Forward Admin Audit Logs to SIEM

All administrative actions in DB Audit (user creation, policy changes, configuration updates) generate audit events. Forward these to your SIEM for independent monitoring and compliance evidence.

Prometheus Alerting

Configure Prometheus alerting rules to detect security-relevant events such as authentication failures, unauthorized access attempts, and configuration changes outside of maintenance windows.

Log Integrity: Append-Only Storage

Store DB Audit logs in append-only or immutable storage to prevent tampering. Recommended approaches include S3 with Object Lock (WORM), Azure Immutable Blob Storage, or a dedicated log server with append-only filesystem mounts. This ensures that even a compromised admin account cannot delete or modify historical audit records.

Example Prometheus Alert

- alert: DBauditUnauthorizedAccess
  expr: dbaudit_auth_failures_total > 10
  for: 5m
  labels:
    severity: critical
  annotations:
    summary: "High number of authentication failures"

Hardening Checklist

Use this checklist to verify your DB Audit deployment meets security hardening requirements. Address all Critical items before going to production, and plan for High and Medium items as part of your ongoing security posture.

Category	Item	Priority
Container	Run as non-root	Critical
Container	Read-only root filesystem	Critical
Container	Drop all capabilities	Critical
Network	Enable NetworkPolicy	Critical
Network	TLS 1.3 for all connections	Critical
Auth	Enforce MFA	Critical
Auth	Session timeout < 30min (admin)	High
Secrets	Use Vault or Sealed Secrets	High
Network	mTLS between components	High
Logging	Forward to SIEM	High
Container	Seccomp profile	Medium
Auth	IP allowlist for admin	Medium