Serverless and Function Security
Least Privilege IAM per Function Serverless functions should receive minimal IAM permissions required for their specific purpose, with separate execution roles per function rather than shared roles across multiple functions. Broad wildcard permissions create excessive blast radius when functions are compromised through code vulnerabilities or dependency exploits. Function permissions should be scoped to specific resources where possible, granting access to individual S3 buckets, DynamoDB tables, or SQS queues rather than all resources of a type. Resource-based policies on accessed services provide defense-in-depth by requiring both function execution role permissions and resource policy allowances. Permission boundaries limit maximum permissions that functions can assume, preventing privilege escalation through IAM policy modifications. Regular permission audits identify and remove unused permissions, reducing attack surface over time. Event Source Protection Serverless functions typically trigger from event sources including queues, storage buckets, API gateways, and message topics. Event source security prevents unauthorized event injection that could trigger malicious function executions or cause denial-of-service through excessive invocations. Resource policies on event sources restrict which principals can publish events, while encryption protects event data in transit and at rest. Event validation within functions verifies event authenticity and structure before processing, preventing injection attacks through malformed events. Rate limiting and concurrency controls prevent resource exhaustion from event floods, while dead letter queues capture failed events for investigation without blocking event processing. Secrets Management Serverless functions should retrieve secrets from secrets managers or parameter stores rather than embedding secrets in environment variables or code. Secrets managers provide encryption, access control, rotation, and audit logging that environment variables lack. Environment variables are visible to anyone with function read permissions and appear in logs and error messages, creating exposure risks. Secrets managers enable fine-grained access control with separate permissions for secret reading versus secret management. Minimize environment variable usage for configuration, preferring runtime secret retrieval that enables secret rotation without function redeployment. Cache secrets within function execution contexts to reduce secrets manager API calls while maintaining reasonable refresh intervals.Managed Service Security
Private Connectivity Managed services should use private endpoints or VPC-native configurations that eliminate public internet exposure. Private endpoints provide private IP addresses within VPCs for managed services, preventing data exfiltration through public endpoints. VPC-native managed services like VPC-native RDS or Elasticache deploy within customer VPCs, enabling network-level access controls through security groups and network ACLs. Service-specific firewall rules restrict access to specific IP ranges or VPC endpoints. Public endpoints should be disabled where possible, with access requiring VPN or bastion host connectivity. When public endpoints are necessary, IP allowlisting and authentication provide defense-in-depth. Audit Logging and Monitoring Managed services should enable comprehensive audit logging that captures data access, configuration changes, and administrative operations. Centralized log aggregation enables correlation across services and long-term retention for compliance and investigation. Managed database audit logs capture query patterns, authentication attempts, and schema modifications. Storage service logs track object access, permission changes, and lifecycle events. Monitoring alerts detect anomalous access patterns that may indicate compromise or data exfiltration. Multi-Tenancy and Data Isolation Managed databases and analytics services often use multi-tenant architectures where multiple customers share underlying infrastructure. Understanding multi-tenant risk models helps organizations make informed decisions about data sensitivity and service selection. Row-level security and column-level encryption provide data isolation within shared databases, preventing cross-tenant data access through application vulnerabilities. Per-tenant encryption keys enable cryptographic isolation with separate key management per tenant. Dedicated instances or single-tenant services eliminate multi-tenant risks but increase costs. Organizations should match service selection to data sensitivity, using dedicated instances for highly sensitive data and multi-tenant services for less sensitive workloads.Cloud-Native Application Protection Platform (CNAPP)
Integrated CSPM, CWPP, and CIEM Cloud-Native Application Protection Platforms integrate Cloud Security Posture Management (CSPM), Cloud Workload Protection Platform (CWPP), and Cloud Infrastructure Entitlement Management (CIEM) into unified security platforms. This integration provides comprehensive visibility from infrastructure configuration through runtime workload behavior and identity permissions. CSPM continuously assesses cloud configurations against security best practices, detecting misconfigurations like public storage buckets, overly permissive security groups, or disabled logging. CWPP provides runtime protection for containers and VMs through vulnerability scanning, malware detection, and behavioral monitoring. CIEM analyzes identity permissions, detecting excessive privileges and unused permissions. Integrated platforms correlate findings across these domains, identifying attack paths that combine configuration weaknesses with excessive permissions and vulnerable workloads. This correlation enables risk-based prioritization that focuses remediation on issues with highest potential impact. Infrastructure-as-Code Scanning IaC scanning analyzes Terraform, CloudFormation, ARM templates, and other infrastructure definitions before deployment, detecting security issues in development rather than production. Scanning as CI/CD gates prevents deployment of infrastructure with known security issues. IaC scanning detects common misconfigurations including unencrypted storage, public network access, missing logging, and excessive IAM permissions. Custom policies enforce organization-specific requirements like mandatory tagging, approved instance types, or geographic restrictions. Scan results should integrate with developer workflows through pull request comments and IDE integrations, providing immediate feedback that enables rapid remediation. Policy violations should block deployment for critical issues while allowing warnings for lower-severity findings. Drift Detection and Auto-Remediation Configuration drift occurs when manual changes or automated processes modify infrastructure outside IaC workflows, creating inconsistencies between desired and actual state. Drift detection identifies these discrepancies, while auto-remediation automatically corrects drift to restore desired state. Auto-remediation should be used carefully, as automatic changes can cause service disruptions if drift resulted from legitimate emergency changes. Remediation workflows should include approval steps for high-impact changes while automatically correcting low-risk drift. Drift metrics identify teams or services with frequent drift, indicating process issues that require workflow improvements rather than just technical remediation.Supply Chain Security
Image and Function Signing Container images and serverless function packages should be cryptographically signed by build systems, with runtime policies requiring valid signatures before deployment. Signing proves that artifacts were built through approved pipelines and haven’t been tampered with since build. Image signing with Docker Content Trust, Notary, or Sigstore provides cryptographic verification of image provenance. Function signing with code signing certificates proves function authenticity. Registry policies can require signatures, preventing deployment of unsigned or invalidly signed artifacts. Provenance Attestations Provenance attestations document artifact build process including source repository, commit hash, build parameters, and security validations performed. Attestations enable verification that artifacts were built from approved source code through approved processes. SLSA provenance provides standardized attestation formats that document build provenance at various assurance levels. Higher SLSA levels require stronger build isolation, more comprehensive provenance, and cryptographic binding between source and artifacts. Deployment policies can require specific SLSA levels for production deployments, ensuring that production artifacts meet minimum supply chain security requirements. Registry Allowlisting Container and artifact registries should be allowlisted, preventing deployment of images from untrusted sources. Allowlisting prevents supply chain attacks through malicious public images or compromised third-party registries. Private registries should be preferred for production deployments, with image promotion workflows that scan, sign, and copy approved public images to private registries. This approach enables security scanning and policy enforcement while maintaining control over deployed artifacts. Runtime Policy Enforcement Runtime policies enforce security requirements during workload execution, complementing build-time and deployment-time controls. Runtime policies can prevent privileged container execution, restrict system calls, enforce network policies, and detect anomalous behavior. Admission controllers in Kubernetes validate and mutate pod specifications before deployment, enforcing security policies like required security contexts, resource limits, and image sources. Runtime security tools monitor container behavior, detecting suspicious activities like unexpected network connections or file modifications.Observability and Monitoring
Distributed Tracing Cloud-native applications span multiple services, functions, and managed services, making request flow difficult to understand without distributed tracing. Tracing correlates requests across service boundaries, enabling performance analysis and security investigation. Trace data reveals service dependencies, identifies performance bottlenecks, and provides forensic evidence during security incidents. Security-relevant trace attributes include authentication context, authorization decisions, and data access patterns. Sampling strategies balance observability with cost and performance impact, with higher sampling rates for error conditions and security-relevant requests. Structured Logging Structured logs with consistent schemas enable automated analysis and correlation across services. JSON-formatted logs with standard fields for request ID, user identity, service name, and timestamp enable efficient querying and alerting. Security-relevant log events should include authentication attempts, authorization decisions, data access, configuration changes, and error conditions. Log aggregation platforms enable centralized search, alerting, and long-term retention. Policy Decision Logging Authorization policy decisions should be logged with sufficient context to understand why access was granted or denied. Policy decision logs enable security investigations, compliance auditing, and policy debugging. Logs should include subject identity, requested resource, action, policy evaluation result, and applicable policies. This information enables reconstruction of access patterns and identification of policy gaps or misconfigurations.Conclusion
Cloud-native security requires rethinking traditional security models to address ephemeral workloads, event-driven architectures, and managed services. Security engineers design cloud-native applications with identity-based access controls, comprehensive observability, and supply chain security that leverages platform capabilities while addressing unique cloud-native threats. Success requires treating security as integral to cloud-native architecture rather than an afterthought, with security controls embedded in development workflows, deployment pipelines, and runtime environments. Organizations that invest in cloud-native security fundamentals build resilient applications that scale securely with business growth.References
- CNCF Security Technical Advisory Group Papers
- AWS Serverless Security Best Practices
- Azure Serverless Security
- Google Cloud Serverless Security
- SLSA Supply Chain Security Framework