Using admission controllers and enabling optional logs collection

Note

The procedures in this topic apply only to ITRS Analytics KOTS installations.

This topic covers advanced security context configuration, including integration with admission controllers, optional features with specific security requirements, and frequently asked questions.

Integration with admission controllers Copied

Gatekeeper Copied

ITRS Analytics is compatible with Gatekeeper policies. Common policy templates:

• K8sPSPCapabilities — drop all capabilities.
• K8sPSPAllowedUsers — enforce UID/GID ranges.
• K8sPSPPrivilegeEscalation — prevent privilege escalation.

Configure your security contexts to match your Gatekeeper constraints.

Kyverno Copied

Similar to Gatekeeper, configure security contexts to match your Kyverno policies.

Pod Security Admission (PSA) Copied

Pod Security Admission is Kubernetes’ built-in admission controller (since v1.23) that enforces Pod Security Standards. ITRS Analytics supports all levels:

• Privileged - Works (but not recommended - no restrictions)
• Baseline - Works with default configuration (blocks obviously dangerous settings)
• Restricted - Works with default configuration (maximum security)

For PSA Restricted level, ITRS Analytics default configuration includes all required fields:

• runAsNonRoot: true
• allowPrivilegeEscalation: false
• capabilities.drop: [ALL]
• seccompProfile.type: RuntimeDefault

To enable PSA for your namespace:

kubectl label namespace <namespace> \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/audit=restricted \
  pod-security.kubernetes.io/warn=restricted

Optional features: Logs collection Copied

ITRS Analytics includes an optional logs collection feature that deploys a DaemonSet (log-collector) to collect container logs from all nodes in the cluster. This feature is disabled by default.

Security requirements

Logs collection has specific security requirements that are incompatible with strict security policies:

• Not compatible with PSS “restricted” level
• Not compatible with PSS “baseline” level
• Only compatible with PSS “privileged” level
• Not compatible with Gatekeeper “drop-all” capability constraints

Why these requirements? Copied

The log-collector DaemonSet requires:

1. hostPath volumes - To read container log files directly from the host filesystem (/var/log/containers, /var/log/pods, /var/lib/docker/containers)
2. allowPrivilegeEscalation: true - Required for the Java binary with file capabilities
3. DAC_OVERRIDE capability - To read log files owned by other users

These requirements violate both PSS “restricted” and “baseline” levels, as well as typical Gatekeeper policies that enforce “drop all capabilities”.

When to enable Copied

Enable logs collection only if:

• Your cluster allows PSS “privileged” level (or no PSS enforcement)
• Your Gatekeeper/Kyverno policies allow DAC_OVERRIDE capability
• Your policies allow hostPath volumes
• You need centralized log collection for all platform components

When to disable Copied

Disable logs collection (keep it disabled) if:

• Your cluster enforces PSS “restricted” or “baseline”
• Your Gatekeeper/Kyverno policies require “drop all capabilities”
• Your policies block hostPath volumes
• You use an external log collection solution

Configuration Copied

Logs collection is controlled by the collection.logs.enabled parameter in your IAXPlatform configuration:

To enable (only if security policies allow):

apiVersion: itrsgroup.com/v1
kind: IAXPlatform
metadata:
  name: iax-production
spec:
  collection:
    logs:
      enabled: true

The log-collector uses a dedicated security context (separate from other platform components):

collection:
  logs:
    securityContext:
      pod:
        runAsUser: 10000
        runAsGroup: 10000
        supplementalGroups: [10000]
        fsGroup: 10000
        fsGroupChangePolicy: OnRootMismatch
      container:
        runAsNonRoot: true
        allowPrivilegeEscalation: true      # Required for setcap binary
        capabilities:
          add: [DAC_OVERRIDE]                # Required to read other users' files
          drop: [ALL]
        seccompProfile:
          type: RuntimeDefault

Note

You cannot override this security context to make logs collection work with PSS “restricted” or “baseline”. The requirements are fundamental to how the log-collector accesses host filesystem logs.

Verification Copied

If you enable logs collection, verify it’s working:

# Check DaemonSet status
kubectl get daemonset log-collector -n itrs

# Check log-collector pods (should be 1 per node)
kubectl get pods -n itrs -l app=log-collector

# Check logs are being collected
kubectl logs -n itrs -l app=log-collector --tail=20

If pods fail with security policy violations:

1. Verify PSS level: kubectl get namespace itrs -o jsonpath='{.metadata.labels.pod-security\.kubernetes\.io/enforce}'
2. Check Gatekeeper constraints: kubectl get constraints -A
3. Disable logs collection: collection.logs.enabled: false

Best practices Copied

1. Default: Keep disabled - Only enable if you have specific requirements and appropriate security policies
2. Security trade-off - Understand that enabling logs collection requires relaxing security policies

Frequently asked questions Copied

Q: Which security context parameters can I change after installation?

A: Critical rule: If you change runAsUser, you MUST also change fsGroup at the same time. This is required for all stateful workloads (PostgreSQL, TimescaleDB, etcd, Kafka) to maintain proper file ownership and permissions.

Safe to change independently:

• fsGroup only
• runAsGroup only
• supplementalGroups only

Requires both to change:

• runAsUser → MUST also change fsGroup

Example of a valid change:

# Before (initial installation)
runAsUser: 10000
fsGroup: 10000

# After (valid change)
runAsUser: 5000
fsGroup: 5000  # MUST change when runAsUser changes

Important

Changing runAsUser post-installation requires manual intervention and temporarily relaxing security policies. See Manual recovery: Change user IDs with strict security policies for the complete procedure. Configure correctly before initial deployment to avoid this complexity.

Q: Can I use different security contexts for different components?

A: No, the security context configuration applies to all ITRS Analytics components. This ensures consistent security posture across the deployment.

Q: What happens if I don’t specify a security context?

A: ITRS Analytics uses sensible defaults (UID 10000, drop all capabilities, non-root). These work for most clusters.

Q: Can I use UID 0 (root)?

A: While technically possible, it’s not recommended and may be blocked by your cluster’s security policies. Use non-root UIDs.

Q: How do I find my cluster’s allowed UID range?

A: This varies by cluster:

• OpenShift: oc describe project <namespace> | grep uid-range
• Kubernetes: Check with your cluster administrator or security policies
• Pod Security Policies: Review PSP spec for allowed ranges

Q: Does changing security context require downtime?

A: Yes, pods need to be recreated with new security contexts. Plan for a maintenance window.

Q: Can I use Linkerd service mesh with strict security policies?

A: Yes, but you must configure Linkerd in CNI mode. The default Linkerd installation uses linkerd-init containers that require NET_ADMIN and NET_RAW capabilities, which conflict with policies requiring “drop all capabilities” (enforced by Pod Security Admission, Gatekeeper, Kyverno, or OpenShift SCCs). CNI mode eliminates these privileged init containers by moving traffic redirection to a node-level DaemonSet. See Troubleshooting or consult the Linkerd CNI documentation.