Skip to main content

Security

Self-Deployed Runtime follows a zero-trust model where every component, connection, and operation is verified, minimized, and observable. This model starts with hardened containers, extends through verified supply chains, and encompasses all network communications and secret management. Critically, runtime applications run entirely within your environment where you control the encryption keys and security policies. Each layer of security builds upon the previous, creating defense in depth.

Container security​

The foundation of Self-Deployed Runtime's security begins with how containers are built and run. Every container starts from a minimal base image and runs with strict limitations that prevent exploitation even if compromised.

Hardened execution environment​

All Self-Deployed Runtime containers run with a strict security context to reduce attack surface:

securityContext:
  runAsNonRoot: true          # Never run as root user
  runAsUser: 1000             # Dedicated non-privileged user
  allowPrivilegeEscalation: false
  capabilities:
    drop: ["ALL"]
  readOnlyRootFilesystem: true

This configuration creates the first security boundary—even if an attacker compromises the application code, they can't escalate privileges, modify the filesystem, or access system capabilities. The use of distroless base images further limits what's available to exploit, containing only the application and its runtime dependencies.

Runtime protections​

Building on the hardened base, additional runtime controls keep containers within strict boundaries:

  • No shell access in containers eliminates common attack vectors
  • Minimal base images (distroless) reduce the attack surface to essential components only
  • Resource limits prevent any single container from exhausting system resources
  • Network policies restrict each container to communicate only with required endpoints

These protections work together—a compromised container can't spawn shells, consume unlimited resources, or communicate with unauthorized systems.

Supply chain integrity​

Before any container reaches your environment, it passes through multiple verification stages that verify both security and authenticity.

Continuous vulnerability scanning​

The security of container images is continuously validated through automated scanning:

All images are scanned with Snyk and Trivy on every change and at regular intervals. These scans detect:

  • Known vulnerabilities (CVEs) and outdated dependencies that may be exploited
  • Security misconfigurations that deviate from best practices
  • Accidentally embedded secrets that may provide unauthorized access
  • License compliance to meet legal requirements

Only images free of Critical and High severity vulnerabilities are released, establishing a baseline security standard before deployment.

Image repository options​

Container images required by Self-Deployed Runtime are hosted on Atlan using the Harbor open source registry. Harbor provides enterprise-grade security features including vulnerability scanning, image signing verification, and access control.

If required, these images can be mirrored or pulled to your private container registry to meet organizational compliance and security requirements. This flexibility ensures Self-Deployed Runtime can operate within your existing container management and security infrastructure.

Image signing and verification​

Beyond scanning, every container is cryptographically signed to verify authenticity:

All containers are signed with Cosign, creating entries in Sigstore's transparency log. This immutable record lets you verify that images haven't been tampered with since they left Atlan's build pipeline. The signing process uses keyless signing via GitHub Actions, ensuring traceability and security without requiring long-lived private keys.

Verification capabilities:

  • Image signature validation with Sigstore's transparency log
  • GitHub workflow identity verification
  • Certificate chain validation through GitHub's OpenID Connect (OIDC) provider

For complete verification steps and examples, see Verify container images guide.

Network security​

With containers secured and verified, the next layer protects how they communicate. Self-Deployed Runtime's network model ensures that even if other controls fail, unauthorized network access remains impossible.

Outbound-only communication​

Self-Deployed Runtime operates with an outbound-only communication model—it initiates all connections and never accepts inbound connections. This fundamental design choice eliminates entire categories of attacks:

  • No exposed ports that can be scanned or exploited
  • No services that can be overwhelmed with requests
  • No authentication challenges from external sources

All traffic to Atlan uses TLS 1.2 or higher, which means the content remains protected even if network traffic is intercepted.

Firewall and routing controls​

The outbound-only model is enforced through firewall rules that explicitly block all inbound traffic while permitting only specific outbound connections:

Use firewall enforcement to permit authorized outbound traffic to Atlan endpoints and block all inbound traffic to the App. For configuration steps, see Configure network security.

Recommended network configuration (example)
firewall_rules:
  outbound_allowed:
    - destination: "*.atlan.com"
      port: 443
      protocol: HTTPS
    - destination: "*.atlan.com"
      port: 443
      protocol: gRPC/TLS
  inbound_blocked:
    - all_traffic: DENY

Advanced networking practices​

For environments requiring additional security, these practices layer on top of the basic network controls:

  • Egress-only endpoints restrict outbound connections to an approved list of external endpoints
  • Private routing through VPC/VNet peering or private endpoints keeps traffic within cloud provider networks
  • Proxy support routes all outbound connections through enterprise proxies for inspection
  • Zero-trust implementation limits communications to required services using IP allowlists or service-specific endpoints
  • Rate limiting on egress prevents data exfiltration if other controls are bypassed
  • TLS certificate pinning prevents man-in-the-middle attacks even with compromised CAs
  • Segregated workloads isolate App instances handling different sensitivity levels

Network monitoring​

Continuous monitoring provides visibility into all network activity:

  • Network logs capture all traffic for anomaly detection and audit trails
  • Connection health checks continuously verify that outbound connections to Atlan endpoints remain secure and functional

This monitoring feeds into the broader observability system, creating a complete picture of App behavior.

Authentication and secret management​

With secure containers communicating over protected networks, the next critical layer manages how the App authenticates and handles secrets. This system ensures credentials never leave your control.

Authentication model​

Self-Deployed Runtime uses OAuth 2.0 client credentials flow for all authentication to Atlan services. Each deployed application receives its own unique Client ID and Client Secret, ensuring credential isolation between applications.

This per-application credential model provides critical security benefits: if one application's credentials are compromised, the impact is limited to that specific application rather than affecting all Self-Deployed Runtime deployments. This follows OAuth 2.0 best practices as defined in RFC 9700.

Key security features:

  • Isolated credentials: Each application has unique credentials
  • Rotation support: Client credentials can be rotated on-demand
  • Secure storage: Credentials retrieved from your secret manager, never hardcoded
  • Audit trail: All authentication events logged for security monitoring

This authentication integrates with your existing identity infrastructure, enabling you to apply your standard rotation and governance policies.

Secret management​

Rather than storing any credentials itself, Self-Deployed Runtime integrates with enterprise secret managers through Dapr's secret store abstraction:

  • Just-in-time retrieval means secrets are fetched only when needed for a specific operation
  • Memory-only storage ensures secrets exist only in application memory during use
  • No transmission to Atlan keeps all credentials within your security perimeter
  • Comprehensive audit logging tracks every secret access for compliance
  • Multi-vault support works with AWS Secrets Manager, Azure Key Vault, HashiCorp Vault, and others

This design ensures that even if an App container is compromised, no credentials can be extracted from disk or logs. All secret access follows your existing security policies and appears in your vault's audit logs.

Logging, monitoring, and incident response​

All these security controls generate observable events, creating a comprehensive audit trail and enabling rapid incident response.

Observability​

Every security-relevant event is captured and made available through multiple channels:

  • Structured logs capture all operations with correlation IDs for tracing
  • Metrics expose performance and security indicators through Prometheus format
  • Health endpoints via the FastAPI server provide real-time status
  • Trace data shows the complete flow of operations across components

These observability streams integrate with your existing monitoring infrastructure, whether that's Splunk, Datadog, CloudWatch, or other platforms.

Incident response​

When security events occur, the comprehensive logging enables rapid response:

  • Emergency contact: [email protected] provides 24/7 security team access
  • Log preservation automatically retains all incident-related logs
  • Coordinated notification ensures customer teams are informed of any impacts
  • Automated responses can revoke credentials or terminate connections based on detected anomalies

The incident response process leverages all the security controls—network isolation limits blast radius, credential rotation stops unauthorized access, and comprehensive logs enable thorough investigation.

Security alerts​

Customers receive automatic notifications for:

  • Critical/High vulnerabilities discovered in deployed images
  • Security patches available for immediate deployment
  • Unusual security events detected in agent behavior
  • Compliance violations or configuration drift

These proactive alerts enable rapid remediation before issues can be exploited.

Compliance and audit​

All these security controls align with enterprise compliance requirements and provide the evidence needed for audits.

Regulatory alignment​

The security architecture supports compliance with major frameworks:

  • SOC 2 Type II validates security controls and their operating effectiveness
  • ISO 27001 aligns with information security management system requirements
  • GDPR ensures appropriate data protection and privacy controls
  • HIPAA provides necessary safeguards for healthcare data (when applicable)
  • PCI DSS meets requirements for payment card data security (when applicable)

Each control maps to specific requirements within these frameworks, simplifying compliance documentation.

Audit capabilities​

The layered security model generates comprehensive audit evidence:

  • Immutable audit logs with cryptographic timestamps prove when events occurred
  • Log integration with SIEM and centralized logging solutions enables enterprise-wide visibility
  • Configurable retention from 30–365 days aligns with your policy requirements
  • Chain of custody tracks data from extraction through delivery to Atlan

This audit trail spans all security layers—from container startup through network connections, authentication events, secret access, and data operations.

See also​