Cloud Native software and security
In this first blog in “ security in cloud native apps” I plan to give a brief overview of security considerations in a cloud native application.
What is cloud native?
Any software that leverages/uses “public” cloud infrastructure and services (IaaS, PaaS, DaaS) to build applications that are:
Loosely coupled , service driven ( i.e. “micro” services)
Runs on containerised environments ( e.g. Docker , OpenVZ, Virtual Box etc)
Support dynamic environments managed using orchestration tools ( Kubernetes)
Aligns to 12 ( or 15 factor) software architectures, development methodologies
Very short time to market leveraging automation (CI/CD), DevSecOps pipelines, automated testing
Can run in less-trustable/zero trust environments
What is Zero trust?
Fundamentally Zero trust is about;
Not trusting any piece of the application architecture or underlying environment.
Always authenticate/ verify ( Continuous verification - Authentication and authorisation ) BUT do not automatically trust users and end points
The verification applies to human users as well as system users ( invokers of API calls, DB access, RPC call etc). All these users need to be identified unambiguously and EACH time.
Caching entitlements wont work! needs continuous and real time verification (and avoid non-repudiation, replays )
Deploy security ( verification, integrity checks, authentication , non-repudiation ) at each step / layer in the architecture.
The traditional network boundary ( which is very clear in a traditional on-premise deployment) vanishes due to application deployed in public cloud. Network can be local, on-premise, public cloud or even a hybrid set up employing a distributed computing environment. Therefore the application cant trust and relinquish its defences to the network or infrastructure layer.
Hence limit the “blast radius” from external or internal breaches through self standing security perimeter at each layer of the architecture
Another term used in articulating the security in each layer and each flow is “Defence in Depth”.
Why zero trust is important in Cloud native architectures?
When using cloud services ( authentication services, API / Web access gateways, firewall products, network layer services like VPN in AWS, vNet in Azure, Credential and RBAC frameworks, disk and storage encryption, OS and VM level access/security , malware scanners , infrastructure , storage) we have to rely on the provider’s capability in providing secure service. For example we assume API gateway in AWS is resilient to DDOS attacks, protection against network level - layer 7, IP, or TCP level breaches and hence we ourselves wont execute penetration tests on a API gateway. When we lose this control and relying on other service providers that can run in shared infrastructure ( Hypervisor segregating the run time environment of a host OS hosting workload/data for different clients where we as users dont have any confidence of whether the privacy and integrity of the one’s data is upheld or whether our code and the underlying data runs in a “secure enclave”). There is an absolute need to “not trust but continuously verify”.
Why Zero trust is complex in cloud native solutions?
As discussed above, use of many external technology services in a public cloud set up increases the possible vectors for infiltration and breach ( i.e. attack vectors). This is a fundamental reason for making Zero trust architecture complex to manage in a cloud set up.
But the change in the very nature of a cloud native applications further increase the possible attack vectors. Let’s dissect this further. There are few dimensions;
Additional layers introduced in a cloud native architecture
In traditional architectures we can easily segregate the technology architecture to two layers;
The Code (the application)
The corporate data center/ private cloud ( that encompass the servers, virtual machines, network stack - all seven layers , storage). Lets call it the Trusted Computing base ( TCB)
Whereas moving into cloud native architectures ( Micro services , API gateways ) and embracing containerised run times (e.g. Docker) managed by container orchestration layers ( Cluster managers like Kubernetes, Openshift) brings additional complexity through the introduction of additional layers , connectivity and roles.
Higher delivery velocity introduced due to automation, CI/CD
With the introduction of automated testing, automated build and deployment processes, automated monitoring, the time to market in delivering software has been reduced dramatically. In traditional engineering processes, security and vulnerability analysis was never in the critical path. There was no need for continuous security and vulnerability assessment. But when application deployments happen intra-day , deployed in public cloud infrastructure , the attack vectors grows exponentially. Therefore unless proactive and in-process security assessments are performed you will be exposing your application to significant security risk.
Left shift in DevOps and production environment awareness
In traditional software delivery set up, there was clear separation between the development/ delivery organisation and the production management teams
The developers didnt know how the application was deployed
The production environment set up was different to developer and test environments:
Where as in cloud native and 12-factor application development, there should be zero disparity between prod and Dev/Test environments. This ensures any infrastructure related issues, misconfigurations , tuning and vulnerabilities were found first at development time and not in production.
Verifying non-functional testing like stress load and more importantly security testing was done quite late in the process. for e.g. Application pen test would have found code related security vulnerabilities like access control failures, command/SQL injection , design flaws , using vulnerable software libraries ( Refer OWASP top 10 vulnerabilities ) quite late in the delivery cycle whereas using;
IDE built-in Software Composition Analysis (SCA) tools
Static Application Security Testing (SAST) tools at development time
Dynamic Application Security tTesting (DAST), Interactive Application Security Testing (IAST) during Developer unit/component testing, QA smoke and regression testing
identification of application related security testing has been shifted left.
This has resulted in;
Developers having a better understanding and appreciation of how their software is run in a production environment, the production considerations to be take care of , especially security postures
incorporate security aspects at design and development stage and prove proactively
Select secure third party libraries
incorporate Software composition analysis at build time
Verify vulnerabilities during development phases ( sprints) using static, dynamic and interactive Application security testing tools
Proliferation of services and access channels
Adopting a cloud native, service based architecture expose another dimension of complexity
Multi-channel access - Web, mobile, API (system to system)
which service can be called by what user under which context.. having 100’s of services makes the verification and monitoring complex
How are access credentials stored, verified and protected across many environments
Support of different IAM ( Identity and access management ) offerings - Google, FB, Okta etc using federated identity solutions like Open ID connect , Oauth 2.
And can the services be made “zero trust compliant”? i.e. non-repudiating , non-repeatable encrypted token verification ( e.g. JWT ) at each API end point
Security considerations in cloud native software
With all this added complexity , and the need to run in a “zero trust” set up, brings in more considerations. The consideration can be put into 4 buckets ( and some times referred as 4Cs)
I like to model this as a Matryoshka doll (dolls of decreasing size placed one inside another).
From inside out;
Code - We know what this is! this encompass the code written (in whatever languages- is most cases it can be more than one ) to implement the application product. This can be the primary attack surface and the “last man standing/ inner most protection ” when it comes to security breaches. This can constitute your own code as well as third party libraries ( open source, commercial) the application is dependent on, that are bundled into binary or run time artefacts ( an .exe , a Fat JAR file etc)
Container - The cloud native env like Docker where the application and its supporting run time environment - e.g. a JVM , run time configurations ( e.g. JVM JRE, network volumes, storage volumes ) can be considered as the run time env ( for e.g. in Docker terms a set of images running in a container of a Docker node). The security consideration in this layer can over areas like Container image/ layers vulnerability assessment, Image signing and verification, Container run time segregation and isolation (e.g. Docker Runtime Classes)
Cluster - The orchestrated environment the containers are executed, life-cycle managed ( create/ delete, hydrated..). It can be Kubernetes, Docker Swarm, Amazon EKS, Redhat Openshift. This layer can cover topics like the security posture of the run time environment , RBAC access to the control plain APIs, Application secrets management ( storage, encryption, delivery)
Cloud - Finally the outer most layer and the layer (and the most abstracted ) and had to be relied on the native cloud provider’s own security realms and standards. This can include topics like end point security, data protection, encryption on transit and storage, OS and host level security including prevention and detection tooling, reporting and SIEM tools, network and infrastructure security, Governance , risk and compliance (PCI, GDPR, HIPAA etc)
In the next article I intend to cover more details for each of these layers.
