The cyrus.sh script installs cyrus-sasl-plain which enables the PLAIN SASL mechanism. This transmits usernames and passwords in cleartext over the network, vulnerable to interception attacks.

**Perspective 1:** The pod mounts sensitive host files including TLS certificates (/etc/fullchain.pem, /etc/privkey.pem), CA certificates (/etc/CA.pem), and configuration files from host paths. These files contain credentials and private keys that could be exposed if the host is compromised or if container escape occurs. **Perspective 2:** Containers lack resource limits (CPU, memory). This could allow resource exhaustion attacks and DoS scenarios. Combined with the mail server nature, this could impact overall infrastructure availability.

Containers lack securityContext configuration. This allows containers to run as root, write to the filesystem, and use all capabilities. Combined with hostPath volumes, this creates a significant attack surface for privilege escalation.

**Perspective 1:** Ports 25, 143, 465, 587, 993, 4190 exposed directly to host via hostPort. Port 25 (SMTP) on hostPort 2525 creates potential relay abuse vector. No rate limiting or connection limits configured. **Perspective 2:** Pod has no NetworkPolicy, allowing unrestricted ingress/egress traffic. Attacker who compromises one container can scan and attack other services in the cluster.

No resource limits (CPU, memory) defined for any container. Allows resource exhaustion attacks, denial of service, and potential container escape via resource overcommit.

All container images use :latest tag (localhost/postfix:latest, localhost/ldap:latest, localhost/cyrus:latest), making builds non-reproducible and vulnerable to supply chain attacks.

Configuration files containing potential PII (user credentials, authentication settings, relay hosts) are mounted directly from host paths. This creates a data exposure risk where host filesystem permissions and access controls may not protect sensitive data adequately.

TLS certificate files (/etc/privkey.pem, /etc/fullchain.pem) are mounted from host paths. There is no verification that these certificates are encrypted at rest on the host filesystem, creating a risk of private key exposure.

PCI-DSS 6.5 and SOC 2 CC6.6 require protection against brute force attacks. Postfix has no rate limiting configured for SMTP authentication, creating vulnerability to credential stuffing attacks.

The script downloads Cyrus IMAP source from GitHub releases without verifying the download integrity (no checksum verification). An attacker could potentially compromise the release server or intercept the download.

Cyrus IMAP source tarball URL is hardcoded. While this is a public URL, it should be verified that no authentication tokens are required for future releases.

Cyrus IMAP source downloaded from GitHub without checksum verification (SHA256/SHA512). Attacker could replace source tarball with malicious code.

curl command downloads from GitHub without timeout or size limits. A malicious or misconfigured URL could cause indefinite download, consuming bandwidth and memory.

Cyrus IMAP source is downloaded via curl without TLS verification or checksum validation, allowing potential MITM attacks or tampered packages.

Downloaded tarball is extracted without validation, allowing potential supply chain attacks through malicious archives.

User 'cyrus' is created with group 'tls' which may have elevated privileges. This could lead to unauthorized access to sensitive data if credentials are compromised.

The cyrus user is created with UID 76 but the container runs with 'restartPolicy: Always' and no explicit user override. If the container runs as root, this creates privilege escalation risk.

LDAP configuration does not enforce TLS encryption for all connections. Personal data transmitted to LDAP may be exposed in transit if TLS is not properly configured.

The slapd.conf configuration includes both 'ldap:///' and 'ldaps:///' protocols. This allows unencrypted LDAP connections over port 389, exposing credentials in cleartext to network sniffing attacks.

OpenLDAP slapd.conf mounted from host path /con/ldap/slapd.conf. Configuration could contain insecure defaults, weak bind settings, or allow anonymous access.

**Perspective 1:** The pod.yaml uses hostPath volumes that mount sensitive host directories (/etc/fullchain.pem, /etc/privkey.pem, /con/*) directly into containers. If a container is compromised, attackers can access host configuration files and potentially escalate to host-level access. **Perspective 2:** The pod.yaml exposes multiple ports (25, 143, 465, 587, 993, 4190) to host ports without network policies. This allows unrestricted network access to mail services, enabling potential DoS and unauthorized access.

All container ports are exposed directly to host ports via hostPort configuration (ports 143, 465, 587, 993, 25, 4190). This bypasses container network isolation and exposes mail services directly to the host network.

The postfix user is added to the 'tls' group but the pod.yaml does not enforce running as the postfix user. This could allow privilege escalation if the container runs with elevated privileges.

TLS certificates mounted but no security context or configuration to enforce TLS-only connections. Postfix could fall back to unencrypted connections.

zypper up with --recommends can pull in many packages and consume significant resources. No timeout or resource limits during build.

The --recommends flag may install additional packages not explicitly required, increasing attack surface.

SOC 2 CC7.3 requires change management. Build scripts lack version control integration or change tracking for infrastructure modifications.

The --without-snmp flag is used, which is good practice. However, this is informational - SNMP could be enabled if needed for monitoring.

**Perspective 1:** The pod configuration has no resource requests or limits defined for any container. Attackers can exhaust host CPU and memory resources by spawning unlimited processes or sending massive amounts of data, causing denial of service to all services in the pod. **Perspective 2:** Multiple SMTP (25, 465, 587), IMAP (143, 993), and LDAP ports are exposed without rate limiting. Attackers can perform connection flooding, mail bombing, or LDAP enumeration attacks that exhaust connection pools and CPU. **Perspective 3:** No max_connections or similar limits are configured for Postfix, Cyrus IMAP, or OpenLDAP. An attacker can open unlimited concurrent connections, exhausting file descriptors and memory. **Perspective 4:** The pod has no resource limits at the pod level, allowing individual containers to consume unlimited resources. Combined with container-level missing limits, this enables resource exhaustion attacks. **Perspective 5:** No NetworkPolicy resources are configured, allowing unrestricted network access. Attackers can flood all exposed ports from any source IP without network-level filtering.

**Perspective 1:** All containers (email-postfix, email-openldap, email-cyrusimapd) lack securityContext configuration. They will run as root by default, allowing full container escape if compromised. No runAsNonRoot, readOnlyRootFilesystem, or privileged: false settings. **Perspective 2:** restartPolicy: Always will restart containers indefinitely, potentially keeping compromised containers running and exposing persistent attack surface.

**Perspective 1:** All containers run without securityContext, allowing them to execute as root by default. No runAsNonRoot or runAsUser restrictions are set. **Perspective 2:** Multiple hostPath volumes mount sensitive host paths (/etc/CA.pem, /etc/privkey.pem, /con/*) directly into containers, allowing container escape if compromised. **Perspective 3:** Container ports map directly to host ports (hostPort), and no networkPolicy is defined to restrict inter-container communication. **Perspective 4:** No resource requests or limits are defined, allowing resource exhaustion attacks.

Sensitive TLS private key (/etc/privkey.pem) and certificates mounted via hostPath without volume encryption or access controls. If container is compromised, attacker gains full TLS credentials.