By Raghav K.
In Part 1 of this series, I gave an overview of zero-trust security architecture. The cloud-native architecture has responded to industry demands for software delivery implementation that automates and channels builds to release and helps with management. Containerization is the answer. Kubernetes with cloud-native architecture has led to a significant shift for organizations adopting the cloud-native approach to build business applications.
The concepts of DevOps also lacked a total end-to-end security solution that had a significant impact on services. DevSecOps was introduced to overcome the security shortcomings of DevOps. In Part 3 of this series, I will explain the concepts of applying zero-trust security with cloud-native microservices and Kubernetes.
The zero-trust security architecture offers robust user authentication and device authorization practices for continued access to the system. This access system does not automatically trust any user, agent, or device whether inside or outside the system. The zero-trust security model does not work on a structure that grants access over the network if the user or device’s IP address is in the trusted network channel. Instead, every access request from any medium must be authenticated and authorized.
The zero-trust security model uses the existing systems (like Alibaba Cloud Resource and Access Management (RAM)) or solutions (like Identity as a Service (IDaaS)) to verify identities before granting access. The zero-trust security model uses most of the same security protocols and services, including multi-factor authentication, orchestration, analytics engine, data encryption, and control policies.
The only difference is that the governance over an entire system is led by and not filtered out using trust policies. There are no trust policies, there are only authorized and unauthorized. The zero-trust architecture also implements the least amount of access required policy. This policy says access will only be assigned using factors like time bound access and specific system access.
The number of devices and the technologies behind them are increasing ten-folds every few years. The Internet of Things (IoT) and the Internet of Everything (IoE) are prime examples. Implementing the zero-trust security architecture is different from implementing Identity and Access Management products. These products have been in the industry for a while. Implementing the zero-trust security architecture is about strategizing a better way of implementing security that is more effective using a previous set of products.
Security is unlike any other system you upgrade or change within your enterprise. The same way DevOps brings a culture change within an organization and requires automation to attain optimal continuous integration and delivery cycles, zero-trust security architecture also requires a cultural shift.
This cultural shift will require decommissioning traditional practices altogether and introducing a significant pattern shift to how security is implemented within an organization. If your organization is considerably large with multiples nodes working across multiple regions, you will face complexities. While these complexities are initially mind-boggling, the benefits that you will leverage will be significantly more.
The zero-trust security model is similar to some things we have used for years:
1. The Access Control Lists (ACL)
An ACL is a list that contains rules that grant or deny access to environments.
2. Principles of Least Privilege
The principle of least privilege only grants the amount of access that is required to complete a task. The principle states, if the subject does not need access, it should not have access.
3. Role-Based Access Control
This access control mechanism is a direct approach to restrict access based on the assigned roles and their associated permissions. This is useful when you have defined specific organizational roles to fathom the width of your solution.
All of these concepts can be the starting point for a zero-trust security practice. However, zero-trust security architecture has more value, security, and authorization compared to the concepts mentioned above:
Implementing the zero-trust security architecture while designing solutions using the cloud-native architecture will enable a safe and secure working environment for your applications to yield maximum productivity.
In Part 3 of this series, I will explain scenarios where you can implement zero-trust security with your cloud-native microservices and containers.
Data Transmission Service(DTS): Data Backup and Disaster Recovery Solution
Zero-Trust Security – Part 3: Zero-Trust Security with Cloud-Native Microservices and Containers
2,599 posts | 762 followers
FollowAlibaba Clouder - February 20, 2021
Alibaba Clouder - March 26, 2020
Alibaba Clouder - February 22, 2021
Alibaba Cloud Native Community - June 18, 2024
Alibaba Clouder - February 26, 2021
Alibaba Developer - January 5, 2022
2,599 posts | 762 followers
FollowSecure your cloud resources with Resource Access Management to define fine-grained access permissions for users and groups
Learn MoreAn enterprise-level continuous delivery tool.
Learn MoreAccelerate software development and delivery by integrating DevOps with the cloud
Learn MoreA service that monitors and records the actions of your Alibaba Cloud account, including the access to and use of Alibaba Cloud services using the Alibaba Cloud Management console, calling API operations, or SDKs.
Learn MoreMore Posts by Alibaba Clouder