Skip to content

Security

PII Eraser is built for regulated environments — finance, healthcare, legal, and government — where security, data sovereignty, and auditability are strict requirements. This page provides a comprehensive overview of PII Eraser's security architecture.

Design Philosophy

PII Eraser's security posture is based on three principles:

  1. Minimize the attack surface. Fewer dependencies, smaller images, and no unnecessary runtime capabilities.
  2. Assume breach. Even if an attacker gains code execution inside the container, the hardening measures limit what they can do.
  3. Zero trust networking. The container should not be able to communicate with anything it does not explicitly need to.

Network Isolation

PII Eraser is designed to operate in fully air-gapped environments with no public internet exposure. PII Eraser does not transmit any information to PII Eraser or any third party — ever. This includes:

  • No usage analytics or telemetry
  • No error reporting or crash dumps
  • No license validation callbacks
  • No DNS lookups to external services

To enforce this isolation, the recommended network architecture includes:

  • Private subnets only: The container should not receive a public IP address or be reachable from the internet.
  • Internal load balancer: Route traffic through an internal load balancer or ingress controller accessible only from within your VPC or VPN.
  • Restricted egress: Block all outbound traffic from the container.

Container Hardening

Distroless Base Image

PII Eraser is built on a Chainguard distroless base image. This image contains only the application runtime and its direct dependencies — no shell, no package manager, no utilities like curl, wget, or ssh. This drastically reduces the number of installed packages and, by extension, the number of known vulnerabilities (CVEs) present in the image and the chance that CVEs appear over time.

PII Eraser targets zero known CVEs at the time of each release build. Because the Chainguard base images are rebuilt daily with the latest security patches, and PII Eraser's dependency tree is kept intentionally small, this target is consistently achievable. As part of our secure release pipeline, every PII Eraser container image is proactively analyzed using industry-standard tools, including Trivy and AWS Enhanced Scanning (Amazon Inspector), before distribution.

Scan It Yourself

We encourage customers to scan the PII Eraser container image with their own vulnerability scanners (e.g., Trivy, Grype, Snyk, Prisma Cloud) as part of their standard CI/CD pipeline. We are confident the results will reflect the minimal attack surface described here.

Compiled Application Code

PII Eraser's Python application modules are compiled to native shared objects (.so files) to reduce tampering risk.

Read-Only Filesystem

PII Eraser is designed to run with a read-only root filesystem. The container requires a single writable temporary directory at /tmp (provided as a tmpfs or emptyDir mount), used for minimal runtime scratch operations.

A read-only filesystem prevents:

  • Malware persistence: An attacker cannot write executables, scripts, or cron jobs to disk.
  • Binary tampering: Application code and model files cannot be modified after deployment.
  • Data staging: Sensitive data cannot be written to the container's filesystem for later exfiltration.

Read-only filesystem is configured at the orchestrator level

You can enforce a read-only root filesystem in your deployment configuration:

  • Docker: Add --read-only to your docker run command or read_only: true in your docker-compose.yml. (Enabled by default in the Docker guide).
  • Kubernetes: Set readOnlyRootFilesystem: true under securityContext in your Pod or Container specification. (Enabled by default in the Kubernetes guide).
  • AWS ECS: Set ReadonlyRootFilesystem: true in your container definition. (Enabled by default in the AWS reference implementation).

Dropped Linux Capabilities

PII Eraser is designed to run with all Linux capabilities dropped. Linux capabilities are fine-grained privileges that, by default, grant containers a subset of root-level powers (e.g., NET_RAW, SYS_CHROOT, SETUID). Dropping all capabilities means the container process cannot:

  • Bind to privileged ports
  • Change file ownership
  • Load kernel modules
  • Access raw network sockets
  • Escalate privileges via setuid binaries

This is more restrictive than the default Docker configuration, which retains a set of capabilities even for non-root containers.

Dropped Linux capabilities are configured at the orchestrator level

You can enforce the dropping of all Linux capabilities in your deployment configuration:

  • Docker: Add --cap-drop=ALL to your docker run command or cap_drop: ["ALL"] in your docker-compose.yml.
  • Kubernetes: Set drop: ["ALL"] under securityContext.capabilities in your Pod or Container specification.
  • AWS ECS: Set drop: ["ALL"] under linuxParameters.capabilities in your Task Definition.

Non-Root Execution

PII Eraser runs as a non-root user (nonroot, UID 65532) by default. This is enforced in the container image itself via the USER nonroot directive. Combined with dropping all capabilities and blocking privilege escalation, this ensures the container process has the absolute minimum permissions required to serve API requests.

Dependency Minimization

PII Eraser maintains an intentionally small dependency tree. High-risk libraries commonly found in ML/NLP containers — such as cryptography, full CUDA toolkits, or large framework packages with deep C extension trees — are excluded from the image. A list of dependencies is available on the Third-Party Licenses page.

This minimal footprint means:

  • Fewer CVEs: Less code means fewer vulnerabilities to patch.
  • Simpler audits: A short dependency list is easier for security teams to review and approve.

AWS CloudFormation Reference Implementation

The AWS CloudFormation reference implementation applies all of the security measures described on this page. The following table summarizes where each control is enforced:

Security Control Where Enforced Template File
Read-only root filesystem ReadonlyRootFilesystem: true on task definition fargate.yaml, ec2.yaml
All capabilities dropped LinuxParameters.Capabilities.Drop: ALL fargate.yaml, ec2.yaml
Non-root user USER nonroot in container image Container image
Internal-only ALB Scheme: internal on load balancer common.yaml
Restricted ingress Security group allows port 8000 from ALB only common.yaml
Restricted egress Security group allows outbound TCP 443 only common.yaml
IMDS credential blocking ECS_AWSVPC_BLOCK_IMDS=true in EC2 user data ec2.yaml
No public IP AssignPublicIp: DISABLED on ECS service fargate.yaml, ec2.yaml
Split IAM roles Separate Task Execution Role and Task Role common.yaml
Least-privilege Task Role Only AWSMarketplaceMeteringRegisterUsage common.yaml
ECS Exec disabled EnableExecuteCommand: false on ECS service fargate.yaml, ec2.yaml
Encrypted storage (EC2) Encrypted: true on EBS volume ec2.yaml
Container Insights containerInsights: enabled on ECS cluster common.yaml

Compliance Considerations

PII Eraser's security architecture is designed to support compliance with common regulatory frameworks encountered in its target industries:

  • GDPR (EU General Data Protection Regulation): PII Eraser processes data entirely within your own infrastructure. No data leaves your environment, and no data is stored by PII Eraser.
  • PCI DSS (Payment Card Industry Data Security Standard): PII Eraser can detect and mask payment card numbers, expiration dates, and CVVs. The read-only filesystem, dropped capabilities, and network isolation controls align with PCI DSS requirements for hardened system configurations.
  • HIPAA (US Health Insurance Portability and Accountability Act): PII Eraser can detect healthcare identifiers and personal health information markers. The absence of data persistence and the air-gapped deployment model support HIPAA's technical safeguard requirements.
  • SOC 2 Type II: The container's stateless design, immutable infrastructure, and auditable security controls (all defined in version-controlled CloudFormation templates) support the security, availability, and confidentiality trust service criteria.