A developer pushes a change to Git.
The CI/CD pipeline builds a container image. That image is uploaded to a registry, scanned, and deployed into Kubernetes. The application starts communicating with other microservices, accesses a database, retrieves secrets, exposes APIs to users, and begins generating logs.
It may look like one deployment.
From a security perspective, it is dozens of moving parts.
Every stage creates another potential security boundary.
That is why cloud-native security cannot be reduced to installing a firewall, scanning containers, or giving developers access to a cloud security dashboard. Modern cloud-native applications are dynamic, distributed and heavily automated. Security needs to exist throughout the software lifecycle, from the first line of code to the running workload.
The Cloud Native Computing Foundation’s security guidance organizes this lifecycle into four continuous phases: Develop, Distribute, Deploy and Runtime.
This guide explains the most important cloud-native security practices for modern applications, including Zero Trust, identity and access management, Kubernetes security, container hardening, secrets management, software supply-chain security, network segmentation, policy as code, monitoring and incident response.
Whether you’re building on AWS, Azure, Google Cloud or a multi-cloud environment, the principles are broadly applicable.
What Is Cloud-Native Security?
Cloud-native security is the practice of protecting applications, infrastructure, identities, data, workloads and software supply chains that operate using cloud-native technologies and development practices.
These environments commonly include:
- Containers
- Kubernetes
- Microservices
- APIs
- Infrastructure as Code
- CI/CD pipelines
- Cloud IAM
- Managed databases
- Serverless services
- Service meshes
- Cloud storage
- Automated deployment systems
- Observability platforms
Traditional applications were often designed around a relatively stable infrastructure perimeter.
Cloud-native applications are different.
A service might be deployed in a container today, replaced tomorrow, scaled from three instances to fifty during a traffic spike, and communicate with several other services across a cluster.
The infrastructure itself becomes dynamic.
Therefore, security must also become dynamic.
CNCF’s Cloud Native Security Whitepaper emphasizes that security should be integrated throughout the lifecycle rather than treated as a separate activity at the beginning or end.
Why Is Cloud-Native Security Different?
Imagine a traditional application:
User → Firewall → Server → Database
Now consider a modern cloud-native application:
User → CDN/WAF → API Gateway → Service A → Service B → Service C → Database
At the same time:
- Kubernetes controls workloads.
- IAM controls access.
- Containers provide the application runtime.
- CI/CD controls deployments.
- Infrastructure as Code controls infrastructure.
- Secrets management controls credentials.
- APIs connect services.
- Cloud services provide storage and compute.
- Monitoring systems collect security events.
The security boundary is no longer simply the network perimeter.
NIST’s Zero Trust architecture guidance for cloud-native applications describes this shift from relying primarily on network location toward identity-based authentication and authorization for users, applications and services.
That leads to a fundamental principle:
Don’t assume something is trustworthy because it is inside your cloud environment. Verify it.
The Four Stages of Cloud-Native Security
One of the most useful ways to understand cloud-native security is to follow the application lifecycle.
1. Develop
Security begins before anything reaches production.
This stage includes:
- Source code
- Dependencies
- Infrastructure as Code
- Kubernetes manifests
- Dockerfiles
- Application configuration
- API definitions
A vulnerable dependency or insecure configuration can eventually become a production vulnerability.
CNCF specifically points out that artifacts created during development, including Infrastructure as Code and container manifests, can become attack vectors when deployed.
Security practices should therefore include:
- Secure coding
- Code review
- SAST
- Dependency scanning
- Secret detection
- Infrastructure-as-Code scanning
- API security testing
- Security testing in pull requests
2. Distribute
Once software is built, it needs to move through the software supply chain.
That may involve:
Source → Build → Container → Registry → Deployment
Every step needs protection.
A compromised dependency, build process or container image can undermine an otherwise secure application.
NIST’s SP 800-204D specifically addresses software supply-chain security in DevSecOps and CI/CD pipelines, covering the processes through which cloud-native software is built, packaged and deployed.
Important controls include:
- Trusted dependencies
- Vulnerability scanning
- Container image scanning
- Artifact signing
- Image verification
- Software Bill of Materials (SBOM)
- Build provenance
- Protected CI/CD credentials
- Secure artifact repositories
CNCF also recommends continually scanning artifacts and using cryptographic signing to help verify workload integrity.
3. Deploy
A secure image can still become an insecure workload if it is deployed incorrectly.
Before deployment, organizations should validate:
- Who can deploy it?
- Which image is being deployed?
- Has the image been scanned?
- Is the image trusted?
- What permissions will the workload receive?
- Can it run as root?
- Which networks can it access?
- Which secrets can it read?
- Does it meet organizational policies?
Kubernetes provides admission controls and policy mechanisms that can validate or restrict API requests before resources are accepted.
This is where policy as code becomes particularly powerful.
Instead of relying on developers to remember every security requirement, the platform can automatically reject configurations that violate defined policies.
4. Runtime
Security doesn’t stop after deployment.
Once the workload is running, organizations need to detect:
- Unexpected network connections
- Suspicious processes
- Privilege changes
- Unusual API activity
- Authentication failures
- Abnormal resource usage
- Unauthorized configuration changes
- Compromised credentials
Kubernetes provides audit logging for security-relevant activity involving users, applications and the control plane.
The goal is not simply to prevent every attack.
It is also to detect, contain and recover from attacks quickly.
The 4C Model: Cloud, Cluster, Container and Code
Another useful way to think about cloud-native security is the Kubernetes-oriented 4C model:
Cloud → Cluster → Container → Code
Each layer depends on the security of the layers beneath it.
Cloud
Protect:
- Cloud accounts
- IAM
- Network configuration
- Storage
- Encryption
- Cloud APIs
- Logging
- Control-plane access
Cluster
Protect:
- Kubernetes API
- RBAC
- Nodes
- Namespaces
- Admission controls
- Network policies
- Secrets
- Audit logging
Container
Protect:
- Container images
- Runtime configuration
- Linux capabilities
- Privileges
- Filesystems
- Dependencies
Code
Protect:
- Application logic
- APIs
- Dependencies
- Authentication
- Authorization
- Input validation
- Business logic
A weakness at any level can affect the entire system.
15 Essential Cloud-Native Security Practices
1. Adopt a Zero Trust Architecture
Zero Trust means removing implicit trust.
A user shouldn’t automatically be trusted because they are connected to the corporate network.
A service shouldn’t automatically trust another service because both are inside the same Kubernetes cluster.
A workload shouldn’t receive broad permissions simply because it needs access to one cloud resource.
NIST’s cloud-native Zero Trust model emphasizes identity-based controls and granular authorization for users, services and applications.
A practical Zero Trust strategy includes:
- Strong identity verification
- Least privilege
- Continuous authorization
- Service identities
- Encrypted service communication
- Device and workload context
- Network segmentation
The goal is simple:
Verify every important interaction instead of assuming trust.
2. Implement Least-Privilege IAM
Identity and access management is one of the most important parts of cloud security.
Every human user, service account, application and workload should have only the permissions it actually needs.
For example:
Bad:
Application → Administrator
Better:
Application → Read specific storage bucket
or:
Application → Read/write specific database resources
AWS’s security guidance recommends a strong identity foundation based on least privilege, separation of duties and reducing dependence on long-lived static credentials.
Regularly review:
- User permissions
- Service-account permissions
- Unused roles
- Privileged accounts
- Temporary credentials
- Cross-account access
One forgotten administrator account can become a serious security liability.
3. Secure Kubernetes RBAC
Kubernetes Role-Based Access Control determines what identities can do within the cluster.
Avoid giving users or workloads permissions they don’t need.
For example, a workload that only needs to read objects in one namespace should not automatically receive cluster-wide administrative access.
Kubernetes recommends granting permissions such as create, update, patch and delete only when necessary and warns against overly broad authorization configurations.
Review:
- Roles
- ClusterRoles
- RoleBindings
- ClusterRoleBindings
- ServiceAccounts
- Privileged users
- Unused permissions
Also pay special attention to permissions that can indirectly enable privilege escalation.
4. Secure Container Images
A container image is part of your application’s software supply chain.
Don’t assume an image is safe simply because it comes from a public registry.
A stronger process looks like this:
Build → Scan → Sign → Store → Verify → Deploy
Use:
- Trusted base images
- Minimal images
- Vulnerability scanning
- Regular image updates
- Image signing
- Signature verification
- Immutable versioning
Kubernetes recommends scanning images before deployment and using container signing to validate image integrity.
Avoid relying on an ambiguous tag such as latest for production workloads when immutable versioning or digests can provide stronger deployment consistency.
5. Protect the Software Supply Chain
Modern applications rarely consist entirely of code written by one organization.
They depend on:
- Open-source libraries
- Package repositories
- Base images
- Build tools
- CI/CD systems
- Plugins
- Third-party services
That creates a large supply-chain attack surface.
Security controls should include:
Dependency scanning
Identify known vulnerable libraries.
SBOMs
A Software Bill of Materials provides visibility into components included in a software artifact.
Artifact signing
Help establish that the artifact came from an expected source and wasn’t modified.
Build provenance
Record how and where an artifact was created.
Protected CI/CD
Restrict who can modify build pipelines and release processes.
NIST’s SP 800-204D specifically recommends integrating software supply-chain security into DevSecOps and CI/CD processes.
6. Never Hard-Code Secrets
One of the easiest security mistakes to make is also one of the most dangerous.
Never put:
- Database passwords
- API keys
- Cloud credentials
- Private keys
- Tokens
directly into source code or public repositories.
For Kubernetes, the Secret API provides a mechanism for sensitive configuration, but Kubernetes explicitly warns that Secret values are base64 encoded rather than inherently encrypted and recommends appropriate protections, including encryption at rest and carefully restricting access.
A mature environment should consider:
- Cloud secret managers
- External secret-management systems
- Short-lived credentials
- Secret rotation
- Access auditing
- Minimal secret exposure
And remember:
Base64 is encoding, not encryption.
7. Apply Network Segmentation
A common cloud-native mistake is allowing every workload to communicate freely with every other workload.
That creates unnecessary lateral-movement opportunities.
Network policies can restrict:
- Pod-to-pod traffic
- Ingress
- Egress
- Namespace communication
- External communication
Kubernetes recommends using NetworkPolicies to allow only expected ingress and egress traffic.
Instead of:
Everything → Everything
aim for:
Service A → Database
Service B → Service C
Frontend → API
and block unnecessary paths.
This is especially valuable if one workload becomes compromised.
8. Harden Containers and Pods
Containers should run with the minimum privileges they need.
Important controls include:
- Don’t run as root unless necessary
- Disable privilege escalation
- Restrict Linux capabilities
- Use appropriate Seccomp profiles
- Use AppArmor or SELinux where appropriate
- Avoid host networking unless required
- Avoid host PID/IPC access
- Use read-only filesystems where practical
Kubernetes recommends security contexts and Linux security controls for hardening containers.
Kubernetes Pod Security Standards also provide three policy levels—Privileged, Baseline and Restricted—with the Restricted profile following stronger workload-hardening practices.
The principle is straightforward:
A container shouldn’t have access to capabilities it doesn’t need.
9. Secure the Kubernetes API
The Kubernetes API is one of the most sensitive components in a cluster.
If an attacker obtains excessive API access, they may be able to manipulate workloads, secrets, networking or other cluster resources.
Kubernetes recommends protecting API communication with TLS and controlling who can access the API.
Security teams should review:
- Authentication
- Authorization
- API exposure
- RBAC
- Audit logs
- Service-account access
- Administrative access
- Network restrictions
Never treat the Kubernetes API as an ordinary application endpoint.
10. Use Policy as Code
Security policies become much more effective when they can be automatically enforced.
Imagine your organization has a rule:
Production containers must not run as root.
Instead of relying on documentation, turn the rule into a machine-enforced policy.
For example:
IF container runs as root
THEN reject deployment
Another:
IF image is not from an approved registry
THEN reject deployment
Another:
IF workload requests privileged access
THEN require explicit approval
Kubernetes supports policy mechanisms such as NetworkPolicy and ValidatingAdmissionPolicy, while the wider ecosystem provides additional policy engines.
Policy as code makes security repeatable.
11. Encrypt Data in Transit and at Rest
Sensitive information should be protected while it moves and while it is stored.
Data in transit
Use TLS for communication between:
- Users and APIs
- Services
- Applications and databases
- Administrative systems
Data at rest
Protect:
- Databases
- Object storage
- Disks
- Backups
- Kubernetes control-plane data
AWS’s security guidance recommends protecting data in transit and at rest using encryption, tokenization and access controls appropriate to the data.
Encryption isn’t a replacement for access control.
It is another layer of defense.
12. Secure APIs
Cloud-native applications are often API-heavy.
Every public API can become an attack surface.
Security controls should include:
- Strong authentication
- Authorization
- Input validation
- Rate limiting
- TLS
- API gateways
- Schema validation
- Logging
- Abuse detection
- Proper error handling
Don’t assume that an internal API is automatically safe.
If a compromised service can call another service without meaningful authorization, attackers may be able to move laterally through the application.
13. Monitor and Audit the Environment
You cannot respond to an attack you cannot see.
Cloud-native monitoring should cover:
Identity
Who logged in?
API
What requests were made?
Kubernetes
Who created, modified or deleted resources?
Network
Which services are communicating?
Runtime
What processes are executing?
Infrastructure
What configuration changed?
Kubernetes audit logs provide a chronological record of security-relevant activity involving users, applications and the control plane.
OWASP’s 2025 Kubernetes Top Ten also identifies inadequate logging and monitoring as a significant Kubernetes risk.
14. Continuously Assess Cloud Security
A security assessment shouldn’t happen once a year and then disappear into a PDF.
Cloud environments change constantly.
A new:
- API
- container
- IAM role
- storage bucket
- Kubernetes service
- dependency
- network rule
can introduce a new risk.
A practical cloud security assessment should examine:
- Asset inventory
- IAM
- Network configuration
- Storage exposure
- Encryption
- Kubernetes configuration
- Container images
- Secrets
- CI/CD
- Logging
- Vulnerabilities
- Incident response
Then prioritize findings according to actual business risk.
15. Prepare for Incident Response
Even excellent security controls can fail.
The question isn’t:
“Can we guarantee we will never be breached?”
A better question is:
“What happens if one workload is compromised tomorrow?”
A cloud-native incident-response plan should cover:
Detect → Contain → Investigate → Eradicate → Recover → Learn
For example:
Detect
Identify unusual behavior.
Contain
Isolate the affected workload or credentials.
Investigate
Determine what happened and what was accessed.
Eradicate
Remove malicious components and close the vulnerability.
Recover
Restore trusted workloads and credentials.
Learn
Update controls so the same incident is less likely to happen again.
CNCF’s cloud-native security guidance also highlights the importance of integrating forensics and incident response into the lifecycle.
A Secure Cloud-Native Security Architecture
A simplified architecture can look like this:
INTERNET
│
▼
CDN / WAF
│
▼
API GATEWAY
│
Authentication
│
▼
┌──────────────────┐
│ SERVICE LAYER │
│ │
│ Service A │
│ Service B │
│ Service C │
└────────┬─────────┘
│
Network Policies
│
▼
KUBERNETES
│
┌─────────────┼─────────────┐
▼ ▼ ▼
Workload A Workload B Workload C
│ │ │
└─────────────┼─────────────┘
▼
Secrets Manager
│
▼
Database / Storage
┌─────────────────────────────────────────┐
│ IAM + Encryption + Logging + Monitoring │
└─────────────────────────────────────────┘
CI/CD → Scan → SBOM → Sign → Policy → Deploy
The key point is that security exists across the architecture rather than in one location.
AWS similarly recommends applying security at multiple layers, maintaining traceability, automating security controls and preparing for security events.
Cloud-Native Security vs Traditional Security
| Area | Traditional Approach | Cloud-Native Approach |
|---|---|---|
| Trust | Network perimeter | Identity and context |
| Infrastructure | Relatively static | Highly dynamic |
| Deployment | Manual | Automated |
| Applications | Often monolithic | Often distributed |
| Security | Separate security stage | Continuous security |
| Configuration | Manual | Infrastructure as Code |
| Policy | Documentation | Policy as Code |
| Credentials | Long-lived | Prefer short-lived |
| Monitoring | Infrastructure focused | Cloud + workload + application |
| Network | Perimeter focused | Segmentation + identity |
| Runtime | Stable servers | Dynamic workloads |
The goal isn’t to abandon traditional controls.
It’s to extend them into a more dynamic environment.
Common Cloud-Native Security Mistakes
Even organizations with sophisticated infrastructure can make basic mistakes.
1. Giving workloads administrator privileges
A service rarely needs unrestricted access.
2. Running everything as root
This can increase the impact of a container compromise.
3. Storing secrets in Git
A secret committed to a repository may remain exposed in its history even after the latest version is deleted.
4. Trusting public container images
A public image isn’t automatically a trusted image.
5. Allowing unrestricted network communication
Flat internal networks can make lateral movement easier.
6. Ignoring Kubernetes RBAC
Excessive permissions can turn a small compromise into cluster-wide access.
7. Treating security as a final CI/CD step
Finding a problem before production is generally preferable to finding it after deployment.
8. Ignoring audit logs
Without useful logs, investigation becomes much harder.
9. Assuming the cloud provider secures everything
Cloud providers secure parts of the underlying service, but customers still have responsibilities for identities, configurations, workloads, applications and data depending on the service model.
10. Assuming Kubernetes is secure by default
Kubernetes provides security mechanisms, but organizations still need to configure and operate them correctly. Kubernetes itself provides extensive security guidance covering API protection, Secrets, workload isolation, network policies, admission control and auditing.
How to Perform a Cloud Security Assessment
If you’re responsible for an existing cloud-native environment, start with these questions.
Identity
- Who has access?
- Which accounts have administrator privileges?
- Which permissions are unused?
- Are service identities overprivileged?
Workloads
- Which containers are running?
- Are they trusted?
- Are images scanned?
- Are containers running as root?
Network
- Which services can communicate?
- Are ingress and egress controlled?
- Are unnecessary ports exposed?
Secrets
- Where are credentials stored?
- Who can access them?
- Are they rotated?
Supply Chain
- Where do dependencies originate?
- Is the build pipeline protected?
- Are artifacts signed?
- Is an SBOM generated?
Kubernetes
- Is RBAC properly configured?
- Are Pod Security controls enforced?
- Is the API protected?
- Are audit logs enabled?
Monitoring
- Can suspicious activity be detected?
- Are important events sent to a central monitoring system?
- Are alerts actionable?
Recovery
- Can compromised workloads be isolated?
- Can credentials be revoked quickly?
- Are backups tested?
This assessment can then be converted into a prioritized remediation plan.
Cloud-Native Security Maturity Model
Not every organization can implement everything at once.
A practical maturity model is more useful.
Level 1: Reactive
Security mainly happens after incidents.
Level 2: Controlled
Basic IAM, encryption, vulnerability scanning and monitoring are established.
Level 3: Automated
Security checks are integrated into CI/CD.
Level 4: Policy-Driven
Automated policies prevent insecure configurations from reaching production.
Level 5: Continuous
Security continuously evaluates:
- Code
- Dependencies
- Infrastructure
- Identities
- Containers
- Kubernetes
- Network
- Runtime behavior
The objective isn’t to buy the most security tools.
It’s to progressively move security closer to the point where risk is created.
Cloud-Native Security Checklist
Use this as a practical starting point:
- MFA enabled for privileged identities
- Least-privilege IAM implemented
- Unused accounts and permissions removed
- Kubernetes RBAC reviewed
- Dedicated ServiceAccounts used
- Secrets removed from source code
- Secrets access restricted
- Secrets encrypted appropriately
- Container images scanned
- Trusted image sources used
- Image signatures verified where appropriate
- SBOM generated for important software
- Containers run without unnecessary privileges
- Root execution restricted
- NetworkPolicies configured
- Kubernetes API access restricted
- TLS enabled
- Data encrypted at rest where appropriate
- Kubernetes audit logging enabled
- Runtime monitoring implemented
- Security policies automated
- CI/CD pipeline protected
- Incident-response procedures documented
- Recovery procedures tested
- Cloud security assessments performed regularly
What Is Changing in Cloud-Native Security?
Cloud-native security continues to evolve because the underlying applications are changing.
Security Is Moving Into the Platform
Security teams increasingly want controls that prevent insecure workloads before they reach production.
Policy engines and admission controls can enforce requirements automatically instead of relying entirely on manual reviews. Kubernetes provides native policy mechanisms and extension points for this purpose.
Software Supply Chains Are Becoming a Core Security Boundary
The application is no longer just the code your developers wrote.
It also includes:
- Dependencies
- Build systems
- Container images
- Registries
- CI/CD
- Deployment artifacts
NIST’s software supply-chain guidance reflects this broader view of application security.
Identity Is Becoming More Important
In a distributed application, IP addresses alone don’t tell you whether a request should be trusted.
A service might move between hosts, containers may be recreated, and workloads can scale dynamically.
Identity-based authorization therefore becomes increasingly important.
NIST’s cloud-native Zero Trust architecture specifically emphasizes application and service identities alongside network controls.
Runtime Security Still Matters
Preventive controls aren’t enough.
A workload can be compromised because of an unknown vulnerability, stolen credential or application-level flaw.
Organizations therefore need visibility into what workloads are actually doing.
Frequently Asked Questions About Cloud-Native Security
What are cloud-native security practices?
Cloud-native security practices are methods used to protect cloud-native applications, infrastructure, workloads, identities and software supply chains. They include least-privilege IAM, Zero Trust, container security, Kubernetes hardening, secrets management, network segmentation, supply-chain security, policy enforcement, monitoring and incident response.
Why is cloud-native security important?
Cloud-native environments are highly distributed and dynamic. Applications can contain many services, containers, APIs and cloud resources that change frequently. Traditional perimeter-only security is therefore insufficient. Security needs to be integrated across development, deployment and runtime.
What are the most important cloud-native security practices?
Start with strong identity and least privilege, secure your software supply chain, scan and verify container images, protect secrets, restrict network communication, harden Kubernetes workloads, enforce policies, monitor the environment and maintain an incident-response plan.
Is Kubernetes secure?
Kubernetes provides numerous security mechanisms, including RBAC, Secrets, Pod Security Standards, NetworkPolicies, admission controls and audit logging. However, those mechanisms need to be configured and operated correctly. Kubernetes maintains extensive official security guidance for clusters and workloads.
What is Zero Trust in cloud-native security?
Zero Trust means avoiding implicit trust based on network location. Users, services and devices should be authenticated and authorized according to defined policies. NIST’s cloud-native Zero Trust guidance emphasizes application and service identities and granular authorization.
What is container security?
Container security involves protecting container images, dependencies, runtime configuration and the underlying environment. Important practices include image scanning, trusted sources, signing, least privilege, non-root execution, security contexts and runtime monitoring.
How should Kubernetes Secrets be secured?
Restrict access to Secrets, encrypt them at rest where appropriate, avoid committing Secret manifests to source repositories and consider short-lived credentials or external secret-management systems for sensitive environments. Kubernetes specifically warns that base64 encoding does not provide confidentiality.
What is cloud security architecture?
Cloud security architecture is the overall design of security controls protecting identities, networks, applications, workloads, data and infrastructure in a cloud environment. In cloud-native systems, this architecture commonly spans IAM, WAF/API gateways, Kubernetes controls, network policies, encryption, secrets management, monitoring and incident response.
What is DevSecOps?
DevSecOps integrates security into development and operations rather than treating security as a final review. In a cloud-native environment, this can mean scanning code, dependencies, Infrastructure as Code and container images during CI/CD while enforcing deployment policies before production.
Final Thoughts: Cloud-Native Security Is a Continuous Process
The biggest mistake organizations can make is thinking of cloud-native security as a product.
It isn’t.
A firewall doesn’t secure the entire application.
A vulnerability scanner doesn’t secure the entire application.
Kubernetes RBAC doesn’t secure the entire application.
And a cloud provider doesn’t automatically secure everything you deploy.
Effective cloud-native security is a system of controls working together.
The strongest environments combine:
Identity + Least Privilege + Zero Trust + Secure Code + Supply-Chain Security + Container Hardening + Kubernetes Security + Network Segmentation + Encryption + Policy + Monitoring + Incident Response
And these controls need to operate throughout the application lifecycle:
Develop → Distribute → Deploy → Runtime.
That is the real difference between simply running an application in the cloud and building a cloud-native environment with security designed into it.
If you’re starting from scratch, don’t try to implement every control simultaneously.
Start with the fundamentals:
secure identities, least privilege, protected secrets, trusted images, restricted workloads, controlled network communication and useful logging.
Then automate those controls.
Once the basics are reliable, move toward policy as code, continuous assessment, supply-chain verification and stronger runtime detection.
The goal isn’t to create an environment where nothing can ever go wrong.
The goal is to make the environment harder to compromise, easier to monitor, faster to contain and safer to recover.
That is what mature cloud-native security looks like. for more Viraviotech.com
Sources and Further Reading
- Cloud Native Computing Foundation — Cloud Native Security Whitepaper: The CNCF framework explains security across the Develop, Distribute, Deploy and Runtime lifecycle.
- Kubernetes — Security: Official Kubernetes guidance covering API security, Secrets, workload protection, NetworkPolicies, admission control and auditing.
