Cloud-native applications have evolved into a standardized architecture consisting of multiple loosely coupled components called microservices (implemented as containers), supported by code for providing application services called service mesh. Both of these components are hosted on a container orchestration and resource management platform, which is called a reference platform in this document. Due to security, business competitiveness, and its inherent structure (loosely coupled application components), this class of applications needs a different application development, deployment, and runtime paradigm. DevSecOps (consisting of three acronyms for Development, Security, and Operations, respectively) has been found to be a facilitating paradigm for these applications with primitives such as Continuous Integration, Continuous Delivery, and Continuous Deployment (CI/CD) pipelines. These pipelines are workflows for taking the developer’s source code through various stages, such as building, testing, packaging, deployment, and operations supported by automated tools with feedback mechanisms. In addition to the application code, and the code for application services (service mesh), the architecture has functional elements for infrastructure (computing, networking, and storage resources), runtime policies (authentication, authorization etc.) and continuous monitoring of the health of the application (Observability), which can be deployed through declarative codes. Thus, separate CI/CD pipelines can be created for all of the five code types.
The objective of this document is to provide guidance for the implementation of DevSecOps primitives for a reference platform hosting a cloud-native application with the functional elements described above. The benefits of this approach for high security assurance and for enabling continuous authority to operate (C-ATO) are also discussed.
Cloud-native applications have evolved into a standardized architecture consisting of multiple loosely coupled components called microservices (implemented as containers), supported by code for providing application services called service mesh. Both of these components are hosted on a container...
See full abstract
Cloud-native applications have evolved into a standardized architecture consisting of multiple loosely coupled components called microservices (implemented as containers), supported by code for providing application services called service mesh. Both of these components are hosted on a container orchestration and resource management platform, which is called a reference platform in this document. Due to security, business competitiveness, and its inherent structure (loosely coupled application components), this class of applications needs a different application development, deployment, and runtime paradigm. DevSecOps (consisting of three acronyms for Development, Security, and Operations, respectively) has been found to be a facilitating paradigm for these applications with primitives such as Continuous Integration, Continuous Delivery, and Continuous Deployment (CI/CD) pipelines. These pipelines are workflows for taking the developer’s source code through various stages, such as building, testing, packaging, deployment, and operations supported by automated tools with feedback mechanisms. In addition to the application code, and the code for application services (service mesh), the architecture has functional elements for infrastructure (computing, networking, and storage resources), runtime policies (authentication, authorization etc.) and continuous monitoring of the health of the application (Observability), which can be deployed through declarative codes. Thus, separate CI/CD pipelines can be created for all of the five code types.
The objective of this document is to provide guidance for the implementation of DevSecOps primitives for a reference platform hosting a cloud-native application with the functional elements described above. The benefits of this approach for high security assurance and for enabling continuous authority to operate (C-ATO) are also discussed.
Hide full abstract
) or https:// don't prove our archive is authentic, only that you securely accessed it. Note that we are working to fix that :)
