Date Published: January 2020
Comments Due:
Email Questions to:
Author(s)
Ramaswamy Chandramouli (NIST), Zack Butcher (Tetrate)
Announcement
As microservices-based applications are increasingly adopted within large enterprises and cloud-based environments, there is a need for a dedicated, scalable-supporting infrastructure that will allow for provisioning a comprehensive set of security services. Called Service Mesh, these security services include—but are not limited to—authentication, authorization, secure service discovery, secure communication, and security monitoring. The deployment of Service Mesh components to enable these services involves multiple configurations.
The purpose of Draft SP 800-204A is to provide deployment recommendations for Service Mesh components that span several runtime aspects of microservices-based applications to meet the security requirements for this class of application for various scenarios.
NOTE: A call for patent claims is included on page iv of this draft. For additional information, see the Information Technology Laboratory (ITL) Patent Policy--Inclusion of Patents in ITL Publications.
The increasing trend in building microservices-based applications calls for addressing security in all aspects of service-to-service interactions due to its unique characteristics. The distributed cross-domain nature of microservices needs secure token service (STS), key management and encryption services for authentication and authorization, as well as secure communication protocols. The ephemeral nature of clustered containers (by which microservices are implemented) calls for secure service discovery. The availability requirement calls for: (a) resiliency techniques such as load balancing, circuit breaking and throttling and (b) continuous monitoring (for the health of the service). The service mesh is the only approach that can facilitate specification of these requirements at a level of abstraction such that it can be uniformly, consistently defined, but at the same time, effectively implemented without making changes to individual microservice code. The purpose of this document is to provide deployment guidance for proxy-based Service Mesh components that collectively form a robust security infrastructure for supporting microservices-based applications.
The increasing trend in building microservices-based applications calls for addressing security in all aspects of service-to-service interactions due to its unique characteristics. The distributed cross-domain nature of microservices needs secure token service (STS), key management and encryption...
See full abstract
The increasing trend in building microservices-based applications calls for addressing security in all aspects of service-to-service interactions due to its unique characteristics. The distributed cross-domain nature of microservices needs secure token service (STS), key management and encryption services for authentication and authorization, as well as secure communication protocols. The ephemeral nature of clustered containers (by which microservices are implemented) calls for secure service discovery. The availability requirement calls for: (a) resiliency techniques such as load balancing, circuit breaking and throttling and (b) continuous monitoring (for the health of the service). The
service mesh is the only approach that can facilitate specification of these requirements at a level of abstraction such that it can be uniformly, consistently defined, but at the same time, effectively implemented without making changes to individual microservice code. The purpose of this document is to provide deployment guidance for proxy-based Service Mesh components that collectively form a robust security infrastructure for supporting microservices-based applications.
Hide full abstract
Keywords
API gateway; Application Programming Interface (API); circuit breaker; load balancing; microservices; Service Mesh; service proxy
Control Families
None selected
) or https:// don't prove our archive is authentic, only that you securely accessed it. Note that we are working to fix that :)
