Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.emergence.ai/llms.txt

Use this file to discover all available pages before exploring further.

​
Network Security

CRAFT implements defense-in-depth network security including TLS encryption, SSRF protection, Kubernetes network policies, and DNS security. This page covers the network security architecture and configuration.

​
TLS Configuration

All external and internal communication is encrypted with TLS:
ChannelProtocolMinimum VersionCertificate Management
Client to API gatewayHTTPSTLS 1.3Managed certificates (Let’s Encrypt, cloud-managed, or custom CA)
Service to serviceHTTPSTLS 1.2Internal CA or service mesh
Service to PostgreSQLTLSTLS 1.2Cloud-managed or custom CA
Service to RedisTLSTLS 1.2Cloud-managed
Keycloak to IdPHTTPSTLS 1.2IdP-managed certificates
Webhook deliveriesHTTPSTLS 1.2Target server certificates
TLS 1.0 and 1.1 are not supported. The platform enforces TLS 1.2 as a minimum and recommends TLS 1.3 for all external connections.

​
SSRF Protection

All outbound HTTP requests are protected against Server-Side Request Forgery (SSRF) attacks. This includes JWS jku fetch, health checks, webhook delivery (planned), and crawler operations.

​
Protection Layers

ProtectionImplementation
Private IP blockingResolved IPs validated against RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), RFC 4193 (fc00::/7), link-local (169.254.0.0/16, fe80::/10), and loopback (127.0.0.0/8, ::1)
DNS pinningDNS resolution performed before connection; resolved IP pinned to prevent TOCTOU rebinding attacks
HTTPS enforcementjku URLs must use HTTPS; webhook targets must use HTTPS in production (when implemented)
Redirect limitingAt most 2 redirects followed, with IP re-validation after each redirect
Domain allowlistsConfigurable per feature (e.g., jku domains, crawl domains)
Response size limitsCrawler responses limited to 1 MB
Timeout enforcementjku fetch: 5 seconds; health checks: 10 seconds (configurable)

​
Per-Context Behavior

Different outbound request types apply SSRF rules differently:
ContextPrivate IPsSSRF CheckNotes
Health checksSkip with UNKNOWN statusYesCards with private-IP endpoints are accepted; health checks are skipped
JWS jku fetchRejectYesHTTPS required; domain allowlist applies
CrawlerRejectYesAdmin-configured domains only
Webhook deliveryRejectYesHTTPS required in production; fire-and-forget

​
Kubernetes Network Policies

The platform uses Kubernetes NetworkPolicies to restrict pod-to-pod communication: 
# Example: Governance service network policy
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: governance-netpol
spec:
  podSelector:
    matchLabels:
      app: governance
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: assets
        - podSelector:
            matchLabels:
              app: utils
      ports:
        - port: 8001
  egress:
    - to:
        - podSelector:
            matchLabels:
              app: keycloak
      ports:
        - port: 8080
    - to:
        - podSelector:
            matchLabels:
              app: openfga
      ports:
        - port: 8080
    - to:
        - podSelector:
            matchLabels:
              app: postgresql
      ports:
        - port: 5432

​
Network Segmentation

The platform services are segmented into security zones:
Receives traffic from external clients via the ingress controller or API gateway. Only the API endpoints and Keycloak login pages are exposed externally.
Contains the platform services (Governance, Assets, Utils) and solution services (Data Insights, Data Governance). Services communicate via internal cluster networking with TLS.
Contains PostgreSQL, Redis, and other data stores. Only accessible from the Application Zone. No direct external access is permitted.
Contains Keycloak and OpenFGA. Keycloak is partially exposed (login pages) while OpenFGA is internal-only.

​
Ingress Security

​
Ingress Controller Configuration

The platform’s ingress controller (NGINX or cloud-managed) enforces:
SettingValuePurpose
ssl-redirecttrueForce HTTPS for all connections
hsts-max-age31536000HTTP Strict Transport Security (1 year)
hsts-include-subdomainstrueApply HSTS to all subdomains
proxy-body-size50mLimit request body size (matches skill package upload limit)
rate-limitingCustomer-configuredPer-route rate limiting at the ingress level (must be configured by deploying organization)

​
Web Application Firewall (WAF)

WAF protection is recommended for all production deployments, especially those processing PHI, financial data, or sensitive enterprise data:
  • GCP: Cloud Armor security policies with OWASP Top 10 managed rules
  • AWS: AWS WAF with AWS Managed Rules (Core Rule Set, Known Bad Inputs)
  • Azure: Azure Front Door or Application Gateway WAF with OWASP 3.2 ruleset
Deployments without WAF should document this as an accepted risk in their security posture. At minimum, enable the cloud provider’s managed OWASP Top 10 rule group and IP reputation-based blocking.

​
DNS Security

ProtectionDescription
DNSSECRecommended for external DNS zones to prevent DNS spoofing
Internal DNSKubernetes CoreDNS for service discovery within the cluster
DNS pinningSSRF protection pins resolved IPs to prevent DNS rebinding
TXT verificationAgent domain verification via DNS TXT records

​
Service Mesh (Optional)

For zero-trust deployments, the platform supports service mesh integration:
  • Automatic mTLS between all pods
  • Authorization policies for fine-grained access control
  • Traffic management and observability
  • PeerAuthentication for strict mTLS enforcement

​
Webhook Security

When released, outbound webhook payloads will include security headers for integrity verification:
HeaderDescription
X-Webhook-IdUnique delivery ID for idempotency
X-Webhook-TimestampISO 8601 timestamp for replay protection
X-Webhook-SignatureHMAC-SHA256 signature of the payload
Receivers should:
  1. Verify the HMAC-SHA256 signature using the shared secret
  2. Reject payloads older than 5 minutes (replay protection)
  3. Use the delivery ID for idempotent processing
Webhook secrets support rotation with a 24-hour overlap period. During rotation, both the old and new secrets are valid for signature verification.

​
Troubleshooting

Check Kubernetes NetworkPolicies. Verify the source pod has egress rules allowing traffic to the destination pod on the correct port. Use kubectl describe networkpolicy to inspect active policies.
Verify the target URL resolves to a public IP address. If the target is behind a private DNS, add the domain to the appropriate allowlist. Health checks for agents with private IPs return UNKNOWN status by design.
Check certificate validity and chain completeness. Verify the server supports TLS 1.2 or higher. For internal services, ensure the internal CA certificate is trusted by all pods.

​
Next Steps

Authentication

Review the authentication architecture and token management.

Data Classification

Understand encryption requirements by data classification level.

Helm Configuration

Configure network-related Helm values for your deployment.

Networking

Infrastructure-level networking configuration for Kubernetes.