ProficientNowTechRFCs
Platform RFCs

RFC-TENANT-SECURITY-0001: Tenant Application Security Architecture

RFC-TENANT-SECURITY-0001                                         Section 0
Category: Standards Track                                             Index

RFC-TENANT-SECURITY-0001: Tenant Application Security Architecture

Index | Next: Introduction →

Document Metadata

FieldValue
RFC NumberRFC-TENANT-SECURITY-0001
TitleTenant Application Security Architecture
StatusDraft
CategoryStandards Track
KindArchitecture
Created2026-02-11
Updated2026-02-11
Version1.0.0
AuthorPlatform Engineering Team
RequiresRFC-IAM-0001, RFC-SECOPS-0001

Abstract

This RFC defines the architecture for network-level security controls protecting tenant applications from external threats. It establishes patterns for Web Application Firewall (WAF) deployment, Kubernetes network policy enforcement, ingress protection, rate limiting, and tenant isolation at the network layer.

The architecture addresses North-South traffic protection—external traffic entering the cluster—as distinct from East-West traffic (service-to-service) governed by RFC-WORKLOAD-IDENTITY. Together, these RFCs provide defense-in-depth across all traffic patterns.

This RFC specifies BunkerWeb as the unified ingress and WAF solution, providing OWASP Core Rule Set protection, bot mitigation, and rate limiting capabilities. Network isolation is enforced through Kubernetes NetworkPolicy resources managed by the existing Calico CNI.

Scope Boundaries

In Scope

ConcernDescription
Web Application FirewallOWASP Top 10 protection at the ingress layer
Kubernetes Network PoliciesNamespace isolation, pod-to-pod traffic restrictions
Ingress ProtectionTLS termination, request validation, routing
Rate LimitingDDoS mitigation, abuse prevention, traffic quotas
Tenant Network IsolationMulti-tenancy segmentation, namespace boundaries
TLS Certificate LifecycleAutomated certificate provisioning and renewal
Egress ControlsControlled outbound traffic from tenant namespaces
Bot MitigationChallenge-based verification for automated threats

Out of Scope

ConcernAddressed ByRationale
Web UI SSO/authenticationRFC-IAM-0001Browser-based OIDC flows handled by Keycloak
Service-to-service mTLSRFC-WORKLOAD-IDENTITYLinkerd handles East-West traffic identity
Service mesh authorizationRFC-WORKLOAD-IDENTITYServerAuthorization policies via Linkerd
Human privileged accessRFC-PAM-0001SSH, database, kubectl via Teleport
Secret storage/rotationRFC-SECOPS-0001Vault as secret authority
Application-level authorizationRFC-IAM-0001Business logic access control

Relationship to Other RFCs

Normative Dependencies

RFCRelationship
RFC-IAM-0001Provides Keycloak integration patterns; WAF exceptions for authentication flows
RFC-SECOPS-0001Vault for secret storage; ESO for TLS certificate distribution

Informative Dependencies

RFCRelationship
RFC-WORKLOAD-IDENTITYService mesh handles traffic after ingress; coordinates handoff boundary
RFC-PAM-0001Network policies may affect privileged access paths
RFC-DEVELOPER-PLATFORMFuture self-service for network policy requests

Traffic Responsibility Boundaries

DirectionGoverning RFCDescription
North-SouthRFC-TENANT-SECURITY (this RFC)External traffic entering the cluster
East-WestRFC-WORKLOAD-IDENTITYService-to-service traffic within the cluster

Table of Contents

Core Sections

SectionFileDescription
0. Index00-index.mdThis file — metadata, abstract, navigation
1. Introduction01-introduction.mdBackground, current state, motivation
2. Requirements02-requirements.mdDesign goals, non-goals, invariants
3. Architecture03-architecture.mdDefense layers, trust boundaries, authority domains
4. Components04-components.mdComponent taxonomy, responsibilities, interfaces

Domain Sections

SectionFileDescription
5. Ingress Security05-ingress-security.mdTLS architecture, routing patterns
6. WAF Architecture06-waf-architecture.mdWAF placement, rule lifecycle, exceptions
7. Network Policies07-network-policies.mdPolicy hierarchy, tenant isolation model
8. Rate Limiting08-rate-limiting.mdTraffic shaping, DDoS mitigation
9. Tenant Isolation09-tenant-isolation.mdMulti-tenancy model, namespace boundaries

Supporting Sections

SectionFileDescription
10. Rationale10-rationale.mdTechnology decisions, alternatives rejected
11. Evolution11-evolution.mdFuture considerations, migration paths

Appendices

AppendixFileDescription
A. Glossaryappendix-a-glossary.mdTerms, diagram index
B. Referencesappendix-b-references.mdNormative, informative, internal references

Reading Paths

Platform Engineers

Recommended reading order for engineers implementing this architecture:

  1. Introduction — Understand the problem space
  2. Requirements — Learn the invariants
  3. Architecture — Grasp the overall design
  4. Components — Understand component responsibilities
  5. Ingress Security — TLS and routing patterns
  6. WAF Architecture — Protection mechanisms

Security Engineers

Recommended reading order for security review:

  1. Requirements — Understand invariants and constraints
  2. Architecture — Trust boundaries and authority domains
  3. WAF Architecture — OWASP protection model
  4. Network Policies — Isolation enforcement
  5. Rationale — Understand design decisions

DevOps/SRE Teams

Recommended reading order for operations teams:

  1. Components — What runs where
  2. Rate Limiting — Traffic management
  3. Tenant Isolation — Namespace patterns
  4. Evolution — Future migration considerations

Application Developers

Recommended reading order for application developers:

  1. Network Policies — How traffic is controlled
  2. Tenant Isolation — Namespace boundaries
  3. Appendix A: Glossary — Terminology reference

Key Concepts

Defense-in-Depth Model

Security Responsibility Matrix

LayerThis RFCOther RFCs
Edge ProtectionRate limiting, IP blocking—
WAFOWASP Top 10 protection—
TLS TerminationCertificate management—
Network PoliciesNamespace isolation—
Service Mesh—RFC-WORKLOAD-IDENTITY
AuthenticationWAF exceptionsRFC-IAM-0001
Secrets—RFC-SECOPS-0001

Document Conventions

Requirement Level Keywords

This document uses requirement level keywords as defined in [RFC2119] and [RFC8174]:

KeywordMeaning
MUSTAbsolute requirement
MUST NOTAbsolute prohibition
SHOULDRecommended but not required
SHOULD NOTNot recommended but not prohibited
MAYOptional

Invariant References

Invariants are referenced as INV-N where N is the invariant number. See Section 2 for complete invariant definitions.

Version History

VersionDateChanges
1.0.02026-02-11Initial release

Document Navigation

PreviousIndexNext
—Table of Contents1. Introduction →

End of Index

Next

Appendix B: References

Next

1. Introduction

On this page