🔐 Stacktic Security Framework Documentation
📋 Table of Contents
- Executive Summary
- Introduction
- Chapter 1: Network Security
- Chapter 2: Access Control
- Chapter 3: Policy Enforcement
- Chapter 4: Traffic Management
- Chapter 5: Data Protection
- Chapter 6: Compliance & Governance
- Chapter 7: CVE Analysis and SBOM
- Chapter 8: LiveView Security Automation
- Chapter 9: Source Code Security
- Chapter 10: Multi-tenancy
- Key Takeaways
📝 Executive Summary
Stacktic provides an automated, metadata-driven security framework that transforms complex security implementations into simplified, manageable processes. This document outlines how Stacktic automates security from infrastructure protection to policies and RBAC, ensuring enterprise-grade security with minimal manual effort.
🎯 Introduction
Why Stacktic Security Framework?
Security Framework Overview
Stacktic is designed to automate security—from infrastructure protection to policies and RBAC. As a metadata-based solution, Stacktic understands stack layers and can automatically deploy and enforce security best practices.
Core Security Principles
- 🔄 Automation First: Security configurations generated automatically
- 🧩 Metadata-Driven: Intelligent security based on stack relationships
- 🛡️ Defense in Depth: Multi-layered security approach
- 📊 Continuous Compliance: Real-time auditing and reporting
Chapter 1: Network Security
1.1 Network Policies and Micro-Segmentation
The Challenge
In real-world Kubernetes environments, NetworkPolicies are rarely used to their full potential because:
- ❌ They're complex to manage
- ❌ Many security teams apply policies only at the cluster level, not at the stack level
- ❌ Micro-segmentation—isolating traffic between stack layers—is challenging and often avoided
The Stacktic Solution
Stacktic automates this complexity by:
- ✅ Analyzing link directions and metadata to generate hundreds of NetworkPolicies automatically
- ✅ Delivering out-of-the-box micro-segmentation in minutes—work that would normally take months
- ✅ Creating granular policies at the stack layer level
Implementation Example
# Example: Generated NetworkPolicy structure
tree networkpolicy | wc -l
3146
# Sample generated policies:
├── networkpolicy__test__strimzi__all__strimzi__egress__ports__strimzi__nr101__lines15.yaml
├── networkpolicy__test__strimzi__all__strimzi__ingress__ports__strimzi__nr100__lines15.yaml
├── networkpolicy__test__strimzi__exception__system__egress__ports__443__nr36__lines18.yaml
├── networkpolicy__test__strimzi__to__minio__egress__ports__9000__nr70__lines18.yaml
└── networkpolicy__test__strimzi__to__postgresql__egress__ports__5432__nr71__lines18.yaml
⚠️ Best Practice: Test and apply these policies in staging first. If your source code or images communicate outside the relationships defined in Stacktic metadata, the application may break. This is expected behavior for the highest security level.
Chapter 2: Access Control
2.1 RBAC Simplified
The Three-Layer RBAC Approach
RBAC (Role-Based Access Control) can be difficult to manage. Stacktic addresses this using a three-layer approach:
| Layer | Description | Benefit |
|---|---|---|
| 1. Component-Level RBAC | Enabled by default on every component | Automatic service account management |
| 2. Link-Level RBAC | Relationships between source code and components | Auto-generated app-level permissions |
| 3. User-Level RBAC | Direct user/group to component linking | Simplified kubectl access management |
Key Features
- 🔐 Automatic Service Account Creation
- 🔗 Relationship-Based Permissions
- 👤 Intuitive User Management
- 📝 Maintainable Configuration
Visual Examples
USER LEVEL RBAC
APP RELATION LEVEL RBAC
Chapter 3: Policy Enforcement
3.1 OPA (Open Policy Agent) Integration
Overview
OPA is central to Stacktic's security enforcement, providing policy-as-code capabilities.
Core Capabilities
Policy Automation
- ✅ Automate policies using labels or namespaces
- ✅ Choose between Dry Run and Enforce modes
- ✅ Dynamic policy testing based on environment
Example Workflow
1. Add securityContext → Check labels
2. Label source code → Apply policies
3. Integrate metadata → Generate audit reports
Advanced Features
| Feature | Description |
|---|---|
| Dynamic Testing | Automates tests based on test environment |
| LiveView Integration | True/false insights directly in UI |
| Source Code Tuning | Adjusts code to meet OPA policies |
💡 Tip: Keep security definitions inside Stacktic to maintain full audit and reporting capabilities. External labels or policies may not appear in audit reports.
Chapter 4: Traffic Management
4.1 Traffic Security
Layer 7 Security Management
Traffic security is managed through components like Istio or APISIX. Stacktic abstracts complex configurations into links and attributes.
Key Capabilities
Traffic Control
- 🚦 Block, route, or control traffic at Layer 7
- 🚦 Limit traffic to specific routes or IP ranges
Authentication
- 🔐 OIDC integration (e.g., Keycloak)
- 🔐 mTLS between services
Traffic Policies
- 🔄 CORS configuration
- 🔄 URL rewriting rules
- 🔄 Rate limiting
Service Mesh Integration
- 🔄 Full Mesh in minutes
- 🔄 Add rules, and specific configuration per link
- 🔄 Centralized Mesh control
See Mesh Example
Chapter 5: Data Protection
5.1 Secrets Management
Comprehensive Secret Lifecycle
Stacktic provides enterprise-grade secrets management with multiple layers of protection.
Core Features
Default Protection
- ✅ All environment variables saved as Kubernetes secrets
- ✅ Automatic secret rotation capabilities
- ✅ Version-controlled secret management
Advanced Security (SOPS Integration)
Features:
- Encrypt secret files in public repositories
- Decrypt only with appropriate keys
- Full lifecycle management:
• Rotate secrets
• Update configurations
• Re-encrypt on demand
Secret Management Workflow
- Create → Environment variables automatically secured
- Encrypt → SOPS encryption for repository storage (optional)
- Deploy → Secrets injected securely at runtime
- Rotate → Automated rotation without disruption
- Audit → Full tracking and compliance reporting
This ensures secrets remain secure, manageable, and version-controlled throughout the entire stack lifecycle.
Chapter 6: Compliance & Governance
6.1 Security Audits and Reports
Comprehensive Reporting
Every configuration and status generated by Stacktic is translated into comprehensive audit reports.
Report Features
| Report Type | Content | Use Case |
|---|---|---|
| Configuration Analysis | Policy conflicts, misconfigurations | Pre-deployment validation |
| Security Posture | Overall security score and gaps | Executive reporting |
| Compliance Report | Standards adherence (CIS, PCI-DSS) | Audit preparation |
| Change Tracking | Configuration drift detection | Continuous monitoring |
Benefits
- 📈 Validate compliance continuously
- 🔍 Identify security gaps proactively
- 📋 CISO-grade reporting out of the box
Report Location
Reports exist in the audit folder in every generated stack repo:
Chapter 7: CVE Analysis and SBOM
7.1 Vulnerability Management
Overview
Stacktic provides comprehensive vulnerability management through CVE (Common Vulnerabilities and Exposures) analysis and SBOM (Software Bill of Materials) generation for every component in your stack.
Core Capabilities
Offline CVE Reports
Stacktic generates offline CVE reports for each component automatically:
| Feature | Description | Benefit |
|---|---|---|
| Component-Level Analysis | CVE reports per component | Identify vulnerabilities before deployment |
| Offline Access | Reports available without external dependencies | Security analysis in air-gapped environments |
| Version-Specific | CVE data matched to exact component versions | Accurate vulnerability assessment |
| Automated Updates | Reports regenerate with version changes | Stay current with security landscape |
Full SBOM Generation
Stacktic creates complete versioning dependency XMLs for SBOM tools out of the box:
SBOM Features:
- Complete dependency tree for all components
- Version tracking across the full stack
- Export formats compatible with standard SBOM tools
- Automated updates on stack changes
Key Benefits
- 🔍 Proactive Security: Identify vulnerabilities before deployment
- 📋 Compliance Ready: SBOM generation for regulatory requirements
- 🔄 Automated Analysis: CVE reports generated with every build
- 📦 Complete Visibility: Full dependency tracking across stack layers
- 🚀 Zero Configuration: Works out of the box for all components
Integration with Security Workflow
Design Stack → Build → Generate SBOM → CVE Analysis → Deploy
↓ ↓
audit/sbom/ audit/cve/
Use Cases
| Scenario | How Stacktic Helps |
|---|---|
| Pre-Deployment | Review CVE reports before production |
| Compliance Audits | Provide SBOM documentation instantly |
| Version Upgrades | Compare CVE profiles between versions |
| Security Reviews | Complete dependency analysis available |
💡 Best Practice: Review CVE reports during the build phase and address high-severity vulnerabilities before deployment to production.
Chapter 8: LiveView Security Automation
8.1 Real-time Security Assessment
Overview
Stacktic LiveView agent provides continuous, real-time security assessment directly from your live cluster, automating security validation across all critical security layers.
Core Capabilities
The LiveView agent validates security posture continuously by monitoring:
Security Validation Areas
| Validation Type | What It Checks | Real-time Alerts |
|---|---|---|
| RBAC Compliance | Role assignments, service accounts, permissions | ✓ Unauthorized access attempts |
| Policy Enforcement | NetworkPolicies, OPA rules, admission controls | ✓ Policy violations |
| Secrets Strength | Encryption status, rotation compliance, exposure | ✓ Weak or exposed secrets |
| Security Breaches | Suspicious activity, unauthorized changes | ✓ Immediate breach detection |
| Endpoints Security | Exposed services, TLS configuration, ingress rules | ✓ Insecure endpoints |
LiveView Architecture
Live Cluster → LiveView Agent → API → Stacktic Platform → UI Dashboard
↓ ↓ ↓ ↓
Metrics Validation Real-time Security
Collection Engine Analysis Insights
Key Features
Automated Security Assessment
- ✅ Continuous Monitoring: Real-time validation of security controls
- ✅ Automated Remediation: Suggestions for fixing detected issues
- ✅ Compliance Verification: Ensures all security policies are active
- ✅ Drift Detection: Identifies configuration changes from desired state
Security Validation Coverage
RBAC Validation:
- Service account permissions
- Role bindings accuracy
- Cluster role assignments
- User access patterns
Policy Validation:
- NetworkPolicy enforcement
- OPA Gatekeeper constraints
- Pod security standards
- Admission webhook status
Secrets Management:
- Encryption verification
- Rotation compliance
- Secret exposure check
- SOPS integration status
Endpoint Security:
- TLS certificate validation
- Ingress configuration
- Service exposure audit
- mTLS verification
Benefits
- 🔍 Proactive Detection: Identify security issues before they become incidents
- 📊 Real-time Insights: Live security posture in UI dashboard
- 🔄 Continuous Compliance: Automated validation of security controls
- 🚨 Instant Alerts: Immediate notification of security violations
- 📈 Trend Analysis: Track security improvements over time
LiveView Dashboard
The LiveView agent provides real-time visibility into:
- Security Score: Overall security posture percentage
- Active Violations: Current policy and RBAC issues
- Vulnerability Status: Live CVE exposure from running components
- Compliance Status: Real-time adherence to security standards
- Remediation Queue: Prioritized list of security improvements
Integration with Audit Reports
LiveView complements static audit reports by providing:
Static Reports (Build Time) LiveView (Runtime)
↓ ↓
CVE Analysis → Active Vulnerability Status
SBOM Generation → Runtime Dependency Validation
Policy Configuration → Policy Enforcement Status
RBAC Design → Active Permission Verification
Secrets Setup → Secrets Strength Monitoring
⚡ Key Advantage: LiveView transforms security from a build-time check into a continuous runtime validation system, ensuring your security posture remains strong throughout the stack lifecycle.
Use Cases
| Scenario | LiveView Response |
|---|---|
| Policy Drift | Alerts when runtime differs from design |
| Unauthorized Access | Immediate notification of RBAC violations |
| Weak Secrets | Flags secrets not meeting strength requirements |
| Security Breach | Real-time detection of suspicious activity |
| Compliance Audit | Live proof of security controls enforcement |
Chapter 9: Source Code Security
9.1 Code Security
Overview
Stacktic provides pre-defined configuration for the container and image level security.
Key Features
1. Tune Your Security Level
Switch on security, add allowed directories:
2. Enable OPA Validation
Enforce OPA to validate your source code configuration:
3. Audit Report
Audit report will identify the source code security level of the full stack.
Identify Missing Policies:
Identify Missing Source Code Security:
Chapter 10: Multi-tenancy
10.1 Multi-tenancy Isolation
The Complete Security Architecture
Kubernetes Namespace Isolation: Recreating VM-Style Security Boundaries
The Lost Art of Workload Isolation
Companies spent 20 years perfecting VM isolation with VLANs, firewalls, and DMZ zones. Then moved to Kubernetes and deployed everything in one flat network with no boundaries.
Stacktc operates on a principle of isolation by default. This means every part of the stack is completely isolated and managed separately. We automate the security relationships between these isolated stack layers — which can represent components like databases, backends, messaging, or observability. Each layer is fully separated and secured by design.
The Security Architecture Evolution
The Complete Isolation Matrix
| Category | Benefit | Without Separation | With Full Separation | Real-World Impact |
|---|---|---|---|---|
| SECURITY | ||||
| Resource Isolation | Larger blast radius; cross-app name/secret clashes | Scoped RBAC/Secrets/NetworkPolicy; smaller blast radius | Breach in app A can't access app B's secrets | |
| RBAC Scope | Complex role definitions with many exceptions | Simple, namespace-scoped roles | Dev team can't accidentally delete prod resources | |
| Network Policies | Difficult to enforce traffic rules | Clear rules per namespace | Database only accessible from its app namespace | |
| Microsegmentation | Not supported | PCI-DSS compliant zones | Pass compliance audits | |
| Admission Control | Forcing rules is complicated | Easy enforcement per namespace | Automated security policies | |
| RESOURCE MANAGEMENT | ||||
| Quota Enforcement | Hard to prevent resource hogging | ResourceQuotas per namespace | Team A can't starve Team B | |
| Cost Attribution | Unclear who's using what | Clear cost per namespace | Accurate billing per department | |
| Capacity Planning | Guesswork on resource needs | Predictable allocation | Guaranteed resources per team | |
| OPERATIONS | ||||
| Cleanup | Manual tracking of resources | kubectl delete ns <name> removes all | One command cleanup | |
| Troubleshooting | Issues affect entire cluster | Problems contained in namespace | Faster debugging | |
| Service Discovery | Complex naming needed | Simple: <service>.<namespace>.svc.cluster.local | db-service vs prod-eu-mysql-primary-db-service | |
| Kustomize/Helm | Harder to isolate environments | Reuse configs across dev/test/prod | Clean environment separation | |
| COMPLIANCE | ||||
| Audit Trails | Mixed logs, hard to filter | Clean audit boundaries | Compliance reports per namespace | |
| Data Sovereignty | Difficult to enforce location | Namespace-specific policies | GDPR compliance | |
| Security Standards | One-size-fits-all policies | Different standards per workload | PCI namespace stricter than dev | |
| DEVELOPMENT | ||||
| Environment Isolation | Risk of cross-environment pollution | Clear dev/staging/prod boundaries | Dev won't affect production | |
| CI/CD Pipelines | Complex deployment logic | Namespace-based deployments | Deploy to namespace = environment | |
| Testing | Hard to create isolated test environments | Spin up temporary namespaces | Each PR gets its own namespace | |
| ADVANCED | ||||
| Service Mesh | Difficult to manage Istio labels | Per-namespace mesh config | mTLS between components | |
| Label Management | Complex across entire cluster | Simple per namespace | Easy GitOps automation |
Implementation Comparison
Without Namespace Separation (What Most Do)
# Everything in default or one namespace
kubectl apply -f entire-stack.yaml
# Problems:
# - All secrets visible to all pods
# - Any pod can talk to database
# - One misconfigured pod can consume all resources
# - Developer mistake can delete production database
# - Compliance auditor fails you immediately
The Bottom Line
Without proper namespace isolation, NetworkPolicies, and multi-layer RBAC, you have LESS security in Kubernetes than you had with VMs from 2005.
This means every part of the stack must be completely isolated and managed separately. We automate the security relationships between these isolated stack layers — which can represent components like databases, backends, messaging, or observability. Each layer is fully separated and secured by design.
Remember: Namespace isolation is not just about NetworkPolicies
- ✅ RBAC boundaries
- ✅ Secret isolation
- ✅ Resource quotas
- ✅ Audit separation
- ✅ Cost tracking
- ✅ Compliance scope
- ✅ Service mesh configuration
- ✅ Admission controls
It's about creating proper security boundaries that match or exceed what we had in the VM world.
🎯 Key Takeaways
What Stacktic Security Framework Delivers
| Feature | Traditional Approach | Stacktic Approach | Time Saved |
|---|---|---|---|
| Network Policies | Manual creation, months of work | Auto-generated from metadata | 95% |
| RBAC Setup | Complex role definitions | Three-layer automation | 80% |
| OPA Policies | Manual policy writing | Template-based automation | 70% |
| Traffic Security | Complex Istio/APISIX configs | Abstracted link attributes | 85% |
| Security Audits | Manual assessment | Continuous automated reports | 90% |
| Secrets Management | Multiple tools needed | Integrated lifecycle | 75% |
| CVE Analysis | Manual vulnerability scanning | Automated offline CVE reports | 85% |
| SBOM Generation | Manual dependency tracking | Auto-generated XMLs | 90% |
| Security Monitoring | Manual cluster inspection | LiveView real-time validation | 95% |
Summary Benefits
✅ Automated Security: Minimal manual configuration required
✅ Compliance Ready: CISO-grade reports out of the box
✅ Best Practices: Enterprise security patterns by default
✅ Micro-segmentation: Zero-trust networking simplified
✅ Full Lifecycle: From development to production security
Next Steps
- 🚀 Deploy test environment with full security enabled
- 📊 Review generated security reports
- 🔧 Tune policies based on your requirements
- ✅ Validate in staging before production
- 📈 Monitor continuous compliance
This document ensures your stacks are secure, compliant, and auditable—with minimal manual effort.