NIST SP 800-204B 日本語訳

NIST Special Publication 800-204B

Ramaswamy Chandramouli

Zack Butcher Aradhna Chetal

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-204B

Ramaswamy Chandramouli Computer Security Division Information Technology Laboratory

Zack Butcher Tetrate San Francisco, CA

Aradhna Chetal TIAA New York, NY

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-204B

August 2021

U.S. Department of Commerce Gina M. Raimondo, Secretary

National Institute of Standards and Technology James K. Olthoff, Performing the Non-Exclusive Functions and Duties of the Under Secretary of Commerce for Standards and Technology & Director, National Institute of Standards and Technology

Authority

This publication has been developed by NIST in accordance with its statutory responsibilities under the Federal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3551 et seq., Public Law (P.L.) 113-283. NIST is responsible for developing information security standards and guidelines, including minimum requirements for federal information systems, but such standards and guidelines shall not apply to national security systems without the express approval of appropriate federal officials exercising policy authority over such systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130.

Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and binding on federal agencies by the Secretary of Commerce under statutory authority. Nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of the OMB, or any other federal official. This publication may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright in the United States. Attribution would, however, be appreciated by NIST.

National Institute of Standards and Technology Special Publication 800-204B Natl. Inst. Stand. Technol. Spec. Publ. 800-204B, 41 pages (August 2021) CODEN: NSPUE2

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-204B

Comments on this publication may be submitted to:

National Institute of Standards and Technology Attn: Computer Security Division, Information Technology Laboratory 100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899-8930 Email: sp800-204b-comments@nist.gov

All comments are subject to release under the Freedom of Information Act (FOIA).

The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the Nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analyses to advance the development and productive use of information technology. ITL’s responsibilities include the development of management, administrative, technical, and physical standards and guidelines for the cost-effective security and privacy of other than national security-related information in federal information systems.

Deployment architecture in cloud-native applications now consists of loosely coupled components, called microservices, with all application services provided through a dedicated infrastructure, called a service mesh, independent of the application code. Two critical security requirements in this architecture are to build (1) the concept of zero trust by enabling mutual authentication in communication between any pair of services and (2) a robust access control mechanism based on an access control such as attribute-based access control (ABAC) that can be used to express a wide set of policies and is scalable in terms of user base, objects (resources), and deployment environment. This document provides deployment guidance for building an authentication and authorization framework within the service mesh that meets these requirements. A reference platform for hosting the microservices-based application and a reference platform for the service mesh are included to illustrate the concepts in the recommendations and provide the context in terms of the components used in real-world deployments.

attribute-based access control; authentication policy; authorization policy; CI/CD; DevSecOps; JSON web token; microservices-based application; mutual TLS; next generation access control; policy enforcement point; role-based access control; service mesh; service proxy; zero trust.

The authors express their sincere thanks to Mr. David Ferraiolo of NIST for initiating this effort to provide a targeted deployment guidance in the form of an authentication and authorization framework in a service mesh environment used for protecting microservices-based applications. They also express thanks to Isabel Van Wyk of NIST for her detailed editorial review.

NOTICE: The Information Technology Laboratory (ITL) has requested that holders of patent claims whose use may be required for compliance with the guidance or requirements of this publication disclose such patent claims to ITL. However, holders of patents are not obligated to respond to ITL calls for patents, and ITL has not undertaken a patent search in order to identify which, if any, patents may apply to this publication.

As of the date of publication and following call(s) for the identification of patent claims whose use may be required for compliance with the guidance or requirements of this publication, no such patent claims have been identified to ITL.

No representation is made or implied by ITL that licenses are not required to avoid patent infringement in the use of this publication.

Two significant features of the application environment in emerging cloud-native applications are:

With the disappearance of a network perimeter because of the need to provide ubiquitous access to applications from multiple remote locations using different types of devices, it is necessary to build the concept of zero trust into the application environment. Furthermore, the cloud-native applications span different domains and, therefore, require increased precision in specifying policy by considering a large set of variables (e.g., service, namespace). The service mesh provides a framework for building these and other operational assurances.

The framework includes:

The service mesh’s native feature to authenticate end-user credentials attached to the request (e.g., using a Java Web Token [JWT]) is augmented in many offerings to provide the ability to call external authentication and authorization systems on behalf of the application. The capability to deploy these authentication and authorization systems as services in the mesh also provides operational assurances for encryption in transit, identity, a PEP, authentication, and authorization for end-user identity.

The objective of this document is to provide deployment guidance for an authentication and authorization framework within a service mesh for microservices-based applications that leverages the features listed above. A reference platform for hosting the microservices-based application and the service mesh is included to illustrate the concepts in the recommendations and provide context in terms of the components used in real-world deployments.

A microservices-based architecture in applications and service mesh application infrastructure that provides various security services through service proxies has emerged as the widespread application environment for cloud-native applications. With the disappearance of the network perimeter due to the need for ubiquitous access to these applications from multiple remote locations using different types of devices, it is necessary to build the concept of zero trust [1] into this application environment. Zero trust assumes that there is no implicit trust granted to assets or user accounts based solely on their physical or network location (i.e., local area networks versus the internet) or based on asset ownership (enterprise or personally owned) [1]. Zero trust focuses on protecting resources (e.g., assets, services, workflows, and network accounts) rather than network segments since the network location is no longer seen as the prime component to the security posture of the resource. Furthermore, the loosely coupled nature of the components (i.e., microservices) of these cloud-native applications facilitates independent design, development, and agile deployment (e.g., Continuous Integration/ Continuous Delivery or Deployment (CI/CD) [2]) of the constituent microservices, enabling paradigms such as DevSecOps [3] (representing Development, Security and Operations) to be used.

The security requirements for microservices-based applications are discussed extensively in [4] and summarized here to provide context for this discussion. They are:

Operating in multiple security domains and multiple clouds, cloud-native applications require a secure authentication and authorization framework. When implemented within the service mesh, the critical requirements of this framework are:

The operational assurances are required for meeting the above requirements, and others are provided by the service mesh. The specific features in the service mesh that enable these are given in the next section.

1

A service mesh provides a framework for building a set of operational assurances for an application through its various features and the set of controls they enable. That framework includes an authenticatable runtime identity for services, the ability to authenticate credentials of individual users of a service, encryption of communication in transit between services, a Policy Enforcement Point (PEP) separately deployable and controllable from the application (e.g., service mesh’s side-car proxy), and logs and metrics for monitoring policy enforcement. Using these mesh features, a set of controls can be built for all applications that are part of the mesh (e.g., all traffic is encrypted, all traffic to an application goes through the side-car proxy [PEP]).

A significant advantage of the service mesh architecture is that the key piece that allows for these controls to be built – the sidecar proxy deployed next to every application – has more security benefits than the traditional approach of building these operational assurances into the application code. First, the life cycle of the sidecar is independent of the application, making it easier to manage across a fleet (e.g., push updates, ensure a consistent version is deployed everywhere). Second, modern implementations (e.g., Istio) allow for dynamic configuration. It is easy to update policies, and updates take effect nearly immediately and without having to redeploy applications. Finally, the mesh’s centralized control allows security teams to build policies that apply to the entire organization so that application developers who build business value are secure by default.

A service mesh provides the ability to authenticate end user credentials attached to the request, like a JSON (JavaScript Object Notation) Web Token (JWT). Many service meshes (e.g., Istio) go further and provide the ability for the mesh’s side-car to call external authentication and authorization systems on behalf of the application. This grants the ability to move request-level policy enforcement out of the application code, trusting instead on the mesh’s assurance that requests that reach the service have been authenticated and authorized for the action that the request is attempting. The mesh can even be configured to pass proof of this to the application. This, coupled with the service mesh’s centralized control, means it is possible for a central team to mandate and manage application-level security across the entire organization, delegating to individual application teams only to specify what permissions are required for each application’s actions.

Using the service mesh architecture also means that authentication and authorization systems can be deployed as services in the mesh. Like any other service in the mesh, they benefit from the operational assurances the mesh provides: encryption in transit, identity, a PEP, authentication, and authorization for end user identity. This makes it cheaper to operate an organization’s authentication and authorization systems securely and reliably.

In addition to the service mesh features, the capabilities of the access control model play an important role in the authentication and authorization framework. Attribute-based access control (ABAC) has emerged as a promising approach for supporting multiple authorization policies (third requirement above). As per [5], ABAC is defined as “an access control method where subject requests to perform operations on objects are granted or denied based on assigned attributes of the subject, assigned attributes of the object, (optionally) environmental conditions, and a set of policies that are specified in terms of those attributes and conditions.” The main focus of this document is to provide guidance on an authentication and authorization framework, the latter using ABAC to secure microservices-based applications using service mesh.

The service mesh is most widely used today with containerized applications but can be extended into other environments, such as stateful applications.

This document focuses on providing guidance for building a secure authentication and authorization framework using components of a service mesh for securing services in microservice-based applications. The framework was developed by highlighting the set of features provided by the service mesh, illustrating how those features can be used to provide operational assurances for applications in the mesh, and making a set of recommendations for settings/defaults for those features that provide the best security posture for applications running on that mesh. The example of running the access control system – one of the most important systems in the organization – on the mesh leveraging those operational assurances makes the system more secure and cheaper to operate than it might be otherwise.

A reference application orchestration and resource management platform and a reference service mesh platform have been used as examples to illustrate these recommendations in the context of real-world application artifacts (e.g., containers and virtual machines (VMs)). The chosen reference application orchestration and resource management platform is the open-source Kubernetes (although other application platforms can be chosen for reference), and the chosen reference service mesh platform is Istio. Application infrastructure components in the service mesh that provide other services like network routing, network resilience, and monitoring are outside of the scope of this document.

The target audience of this guidance document for developing an authentication and authorization framework for microservices-based applications using the service mesh includes:

3

This guidance focuses on building an authentication and authorization framework within the service mesh used for securing microservices-based applications. The following publications provide background information for the contents of this document:

The organization of this document is as follows:

4

The fundamental building blocks in a Kubernetes platform are: pod, node, cluster, and control plane components. A pod is the smallest object deployed, represents a set of running containers, and is identified by a label that is a name/value pair. A node is a physical or virtual machine that houses a set of pods as well as the interfaces necessary to run the housed pods. The set of nodes is called a cluster.

Security

In order to describe the generic service mesh functions in the context of the reference platform – which, in this case, is Kubernetes – the deployment details of both the microservices application and service mesh components in that platform must be considered. Since authentication and authorization functions are the focus of this document, discussions for those functions on the Kubernetes platform will be confined to the functions in the service mesh.

A service mesh not only provides various application services during runtime but also supports the DevSecOps development and maintenance paradigm. The development team can concentrate their efforts on efficient development paradigms, such as application architecture (code modularity and structuring) and secure deployment (including interaction with sidecars and data flows through PEPs), without worrying about the implementation (development and deployment) of all infrastructure services, including many aspects of security. The service mesh is reference platform-aware and thus automatically injects sidecar containers into the pods. Once the service mesh inserts the sidecar containers, the combined team of developers, operations, and security teams can define policies, deploy them, and monitor their enforcements during runtime. These teams can also configure monitoring of the microservices applications without interfering with the functioning of the applications.

8

Attribute-based access control (ABAC) is an authorization framework or engine that computes decisions for user access requests based on attributes (properties) of users (subjects), application objects (resources), and the environment and policies expressed in terms of the attributes [5]. The advantages of ABAC for microservices-based applications using service mesh include:

Due to the features described above, the ABAC authorization framework is a natural fit for the class of cloud-native applications whose design is based on microservices (with each being developed and deployed by independent teams).

The ABAC framework has two standardized, representational structures.

The functional architectures for these two representational structures are given in Figures 3.1 and 3.2, respectively. It must be mentioned that there are certain open-source access control engines, such as Open Policy Agent (OPA) and Casbin, that have the capability to define ABAC policies and enforce them just like XACML implementations. A brief description of the modules in these two functional architectures is as follows:

Figure 3.1 ABAC Functional Architecture based on XACML Representation

11

Figure 3.2 ABAC Functional Architecture based on NGAC Representation

In the context of a microservices-based application using service mesh, an ABAC deployment can take the following forms:

12

Fine-grained access control for microservices can be enforced through the configuration of authentication and access control policies. These policies are defined in the control plane of the service mesh, mapped into low-level configurations, and pushed into the sidecar proxies that form the data plane of the service mesh. The configurations enable the proxies to enforce the policies at application runtime (or request time), thus making the proxies act as Policy Enforcement Points (PEPs). As stated in the introduction, the objective of this document is to provide guidance for the deployment of an authentication and authorization framework that is external to the application and agnostic to the platform hosting the application and the service mesh product that implements the application infrastructure. However, Kubernetes is used as the reference application platform and Istio as the service mesh infrastructure platform to provide concrete examples of the concepts and to allow for recommendations with more clarity and specificity.

The reference application orchestration and resource management platform configuration data for microservices-based applications using service mesh that are, at the minimum, needed for authentication and authorization policy configuration are:

In the instance of the reference platform Kubernetes, this is realized as:

The installation of any service mesh involves the following components:

Having looked at the components in service mesh, we will now look at the minimal requirements for setting up mutual TLS authentication [14] for communication between Kubernetes workloads using these components as a pre-requisite for configuring and enforcing authentication and authorization policies. These requirements or recommendations come under initial service mesh configuration and are numbered using the acronym ISMC-SR-X, where ISMC stands for initial service mesh configuration, SR stands for security recommendation, and X is the sequence number. They include but are not limited to the following.

ISMC-SR-1: If certificate-based authentication is used for authenticating service calls, the signing certificate used by the service mesh’s CA module should be rooted in the organization’s existing Public Key Infrastructure (PKI) to allow for auditability, rotation, and revocation.

Some service meshes come with the ability to encrypt traffic using a self-signed certificate; such a certificate should not be used in secure deployments.

ISMC-SR-2: Communication between the service mesh control plane and the application orchestration and resource management platform’s configuration server must be authenticated and authorized.

In this reference platform, authentication is typically achieved by the Kubernetes API server (the configuration server) with simple TLS. Authentication of the client is based on the pod’s service account credential. Authorization for the client to receive platform information from the API server is enforced by Kubernetes RBAC.

Authentication policies specify the process for validating identities. The integrity of this process and its strength determines the integrity of the authorization process since the latter depends on the strength of the authenticated identity. There are two types of identity needed in a microservices-based application:

Service (microservice) identity is critical for the following reasons:

Associated with these identities are the corresponding authentication processes that the service meshes have to support:

It is assumed that the reference hosting platform has been configured with the high-level requirements outlined in Section 4.1. It is also assumed that the reference service mesh platform has been installed and configured with the initial requirements outlined in Section 4.2.

Service-level authentication is the mutual authentication of the communicating services and setup of a secure TLS session. Enabling this requires the capability to define a policy object, which should meet the following requirements. These requirements are enablers for service-level authentication and are numbered using the acronym SAUN-SR-X, where SAUN stands for service-level authentication, SR stands for security recommendation, and X is the sequence number.:

SAUN-SR-1: A policy object relating to service-level authentication should be defined that requires mTLS be used for communication. The policy object should be expressive enough to be defined at various levels (given below) with features for overrides at the lower levels or inheritance of the requirement specified at the higher levels.

The following are the minimum required levels [6]:

This form of authentication also requires assigning a strong identity to each service, authenticating that identity by mapping it to the server identity (where the service is hosted) and establishing the authenticity of the mapping using a digital signature. One way of implementing this is through a special digital authentication certificate (Secure Production Identity Framework for Everyone (SPIFFE)). To provide assurance that the server whose identity is found in the SPIFFE certificate is the one that is authorized to run the target service, the following requirements (also specified in SP 800-204A) are needed.

SAUN-SR-2: If the certificate used for mTLS carries server identity, then the service mesh should provide a secure naming service that maps the server identity to the microservice name that is provided by the secure discovery service or DNS. This requirement is needed to ensure that the server is the authorized location for the microservices and to protect against network hijacking.

The information for mapping the server identity to a service is obtained by the control plane of the service mesh by accessing the configuration information from the platform that is hosting the microservices-based application. In Kubernetes, the control plane of the service mesh obtains the mapping information through the API server module of the Kubernetes platform and populates that information in the secure naming service. Thus, the mutual certificate validation not only enables validation of the associated service identities of both the client and target services but also enables creation of a secure mTLS session. In Istio, the policy object for this type of authentication is called “peer authentication.”

For the mesh to authenticate end user credentials (EUC), the application must participate in some way. Client services that make the request should acquire and attach an appropriate credential to each request (e.g., a JWT) in the request header. End user authentication, or request authentication, is the process of validating the credentials of the end user making a request by extracting them from the request’s metadata and authenticating them (locally or against an external server). For example, a common flow at many organizations is to exchange an external EUC, like an Oauth bearer token, at ingress for an internal credential that is encoded within a JWT. The JWT can be created by a custom authentication provider or standards-based OpenID Connect provider.

The minimal information requirement in an end user authentication policy is designated using the acronym EAUN-SR-X, where EAUN stands for end user authentication, SR stands for security recommendation, and X is the sequence number.:

EAUN-SR-1: A request authentication policy must, at the minimum, provide the following information and must be enforced by the sidecar proxy:

For a JWT, this might include:

Authorization policies, just like their authentication counterparts, can be specified at the service level as well as the end user level. In addition, authorization policies are expressed based on constructs of an access control model and may vary based on the nature of the application and enterprise-level directives. Further, the location of the access control data may vary depending on the identity and access management infrastructure in the enterprise. These variations result in the following variables:

The supported access control in the service mesh uses abstraction to group one or more policy components (described below in Section 4.5.1) for specifying either service-level or end user-level authorization policies. Since microservices-based applications are implemented as APIs (e.g., Representational State Transfer (REST)ful API), authorization policy components described using key/value pairs will have attributes pertaining to an API, including the associated network protocols. The types of authorization policies are:

Service-level authorization policies are defined using a policy object that provides positive or negative permission (authorization) with the following policy components:

a. The scope of the policy can span all applications at the service mesh level, namespace level, or one or more designated applications (microservice level). b. The permissions or operations can be restricted to one or more designated methods of a given service (e.g., an “HTTP GET method on the ‘/details’ path of an application named PRODUCT-CATALOG”) or to designated ports through which an application can be accessed. c. Conditions under which access can take place (e.g., possession of a token) are specified. d. Sources allowed access are specified at the namespace or a particular service level (in terms of the service’s runtime identity).

The requirements for a policy object for enabling service-level authorization policies are numbered using the acronym SAUZ-SR-X, where SAUZ stands for service-level authorization, SR stands for security recommendation, and X is the sequence number:

SAUZ-SR-1: “A policy object describing service-to-service access should be in place for all services in the mesh. At a minimum, these policies should restrict access to the namespace level (e.g., “services in namespace A can call services in namespace B”). Ideally, policies should restrict access to individual services (e.g., “service Foo in namespace A can call service Bar in namespace B”).”

Policies should describe the minimum access required for application functionality (e.g., “service ‘foo’ in namespace A can perform ‘GET /bar’ on service ‘bar’ in namespace B”).

Given an authentication policy like Section 4.4.3, a sidecar in the mesh can extract a principal from the request to perform authorization on. Further, the sidecar typically has additional context about the request, including the resource being accessed (e.g., the path in an HTTP/REST API) and the action being taken (e.g., the HTTP verbs GET and PUT in the request to that API). This gives the sidecar enough information to act as a PEP and call a policy decision point.

This is the most common case, especially for organizations with traditional Identity and Access Management (IAM) systems that exist as an external service, often called by an Software Development Kit (SDK). To handle this case, a service mesh’s sidecar proxy will typically support calling external services to render an authentication and authorization verdict. For example, the reference implementation Istio supports this via Envoy’s (i.e., the sidecar proxy) external authorization service [15].

The requirements for enabling end-user level authorization policies are numbered using the acronym EAUZ-SR-X, where EAUZ stands for end-user level authorization, SR stands for security recommendation, and X is the sequence number:

EUAZ-SR-1: When a sidecar communicates with an authentication or authorization system, that communication must be secured with either the mesh’s built-in service-to-service authentication and authorization capabilities or using an existing enterprise Identity and Access Management (IAM) that is not part of the service mesh.

An example is the external Software as a Service (SaaS) IAM, such as AuthO.

EUAZ-SR-2: The sidecar should generate logs for every service request to ensure that authentication and authorization policies are enforced and relay telemetry data for the generation of metrics to ensure no degradation of service that will impact availability.

End user authorization is not applied to the decision endpoint of the external authorization (PDP) service since the service is the principal making the call. It also avoids needing a default policy that allows all users to call the decision endpoint of the PDP. End user authorization should be applied to the PAP and other administrative endpoints of the authorization system, and applying that authorization can be facilitated by the mesh.

However, there is another case that is common enough to address in which an external authorization system is not required. Making a network call to an authorization service for every hop in a service chain can be expensive and cause centralized failures. To mitigate these problems, many organizations will exchange end user credentials at ingress for an internal, trusted, authenticatable credential that conveys not just the user’s principal but also that user’s capabilities in the system. A JWT is frequently used for this because it is locally authenticatable and conveys the user’s principal (the JWT’s subject), the issuer of the JWT (issuer), and arbitrary claims that the organization can control (e.g., to use for access control).

Performing end user authorization based on a JWT is built directly into Envoy, the sidecar proxy of the reference mesh Istio. Envoy can be configured with a filter [16] that will process requests in two steps:

Envoy’s JWT filter acts as the PDP, making the access decision entirely locally. This requires that policy documents be small enough to reside on an individual sidecar proxy. Although a full ABAC is ideal for handling resource-level policies, the JWT filter is valuable as a steppingstone from a traditional system that only performs access control on the edge to a zero-trust system that performs authentication and authorization at each service. The limitation of this approach is that it becomes hard to revoke a user’s access once a JWT is issued. Community standards, such as Internet Engineering Task Force (IETF) Request for Comments (RFC) for OAuth2 Introspection, can be used to address this.

An example of an authorization policy that will enable the sidecar itself to make an access control decision based on claims in the JWT and enforce it, without calling on an external authorization system, is given below: apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: name: backend namespace: product spec: action: ALLOW rules: - from: - source: principals: ["cluster.local/ns/product/sa/frontend"] to: - operation: methods: ["GET"] paths: ["/info*"] - operation: methods: ["POST"] paths: ["/data"] when: - key: request.auth.claims[iss] values: ["accounts.google.com"]

Figure 4.1 – An example Istio authorization policy

This allows the front end to call specific methods on the backend only if the request has an EUC attached issued by “accounts.google.com.”

EUAZ-SR-3: All application traffic should carry end user credentials, and there should be a policy in the mesh enforcing that credentials are present.

This is recommended even if the application is enforcing authentication and authorization independently of the mesh because these organization-wide controls allow functionalities like audit to be built on top of the mesh at a lower cost to central teams responsible for compliance and controls.

The service-level authorization policies and a use case of end-user authorization policies that uses JWT are natively implemented in the proxies. Since these cannot be used for resource-level authorization policies, support for model-based authorization policies is needed as well. As already alluded to in Section 4.5.2, this requires a call from the proxy to an external authorization server, which holds the model-based authorization engine to obtain an access decision.

The service principals in these model-based policies are identities (e.g., Service Account) provided by the underlying application orchestration platform (e.g., Kubernetes) and are the same as those used by authorization policies natively supported in the proxies. The user principals are usually obtained from the JWT. The popular access control models in the external authorization servers are RBAC and ABAC.

The requirements that stipulate the minimal set of policy elements that should be present in authorization policies are given below and are numbered using the acronym APE-SR-X, where APE stands for authorization policy elements, SR stands for security recommendation, and X is the sequence number:

APE-SR-1: The authorization policy should, at the minimum, contain the following policy elements:

Positive and negative policies are specified in order to set precedence relationships (e.g., DENY overrides and ALLOW). They are also used for situations that allow one type of policy for all services under a group and to specify exceptions (e.g., have an ALLOW policy for all services in a namespace but a DENY policy for a specified service)

This refers to the target resources in terms of a set of services, versions, and the namespaces under which the services are located. The service can be specified in the following ways:

The policy sources are the set of services that are authorized to operate on the set of resources specified under the policy target (specified using name, path, host name, and ports). The policy sources are usually specified using a service account or name (called principal), all services in a particular logical group (e.g., namespace), or all services that are accessed from a group of network locations (e.g., IP blocks). Both included and excluded principals, namespaces, and IP blocks can be specified in some implementations.

APE-SR-2: The policy should cover all of the operations that are part of the application type. For example, if the application is implemented as a REST API, all of the operations (also called HTTP verbs or HTTP methods) that are part of the REST API must be included:

POST: This is equivalent to creating a resource.

GET: This is equivalent to reading the contents of the resource.

PUT: This is equivalent to updating the resource by replacing.

PATCH: This is equivalent to updating the resource by modifying.

DELETE: This is equivalent to deleting the resource.

If the resource is accessed using gRPC instead of a RESTful protocol, there is only one operation or method: “POST.” The authorization policy definition may also have a feature to specify the list of operations (methods) to be excluded. Both policy sub-elements – one to specify the operations to be included in the authorization policy scope and the other to be excluded – are optional.

Policy conditions specify the constraints in the form of a key-value pair for the metadata associated with the request. This metadata may cover the following:

APE-SR-3: A default policy should be authored in the system that rejects all requests that are unauthenticated, mandates that service and end-user credentials be present on every request, restricts all communication to services within the application’s own namespace, and allows service communication across namespaces only through an explicit policy.

The last section introduced three different types of authorization policies, including two use cases for end-user level authorization policies. This section will leverage those architectural choices to describe an ABAC-based authorization framework in the service mesh:

The authorization policy enforcement mechanism implemented in the service mesh for a microservices-based application must satisfy the three requirements of a reference monitor concept. It must be 1) non-bypassable, 2) protected from modification, and 3) verified and tested to be correct. These three requirements can be ensured by the following:

In short, a proxy running in the data plane of the service mesh is the reference monitor with respect to authorization enforcement. The authorization policy engine (e.g., NGAC-based ABAC policy engine) implemented as a container executing either natively in the proxy memory space or callable from a corresponding filter module in the proxy runs as a separate process that does not share any memory space with the calling application. Hence, it satisfies the requirement of a security kernel.

Now consider the basic building blocks of the supporting infrastructure for service-to-service and end user + service-to-service requests.

The policy object used for authorizing this type of request was described in Section 4.5.1. Service-to-service requests must be authorized based on the identity of the calling and called services. The trusted document that carries the identity of the service is an X.509 certificate issued by one of the control plane components of the service mesh after verifying whether the requested identity is valid for the microservice by consulting an identity registry. The proxy communicates with this control plane component through a local agent, obtains a certificate, and sends it to the proxy, which then performs the certificate validation process on behalf of the calling service or client during each service request. The identity is encoded as URI and carried in a certificate’s SAN (subject alternate name) field. It must be mentioned that the certificates that carry service account identities are short-lived certificates (rotated every hour or few hours) rather than the conventional HTTPS TLS terminating certificates whose validity lasts for several months.

The policy object used for authorizing this type of request was described in Section 4.5.2. This request type requires the verification of two identities: the calling user identity and the service identity. As described in the previous section, the service mesh provides the feature to perform authorization based on service identities. Since this is a standard feature, no extra components need to be built in the service mesh infrastructure for this type of authorization. However, when end user identities are introduced for authorization, the authorization framework should be tightly integrated with the following components of the architecture:

An advantage of an EU+SVC-SVC request processing scheme is that authorizations at a finer level of granularity than the method level can be specified, and conformant claims can be included in the authorization token. A disadvantage is that there is overhead involved in enforcing two layers of authorization – one layer based on policies specified for SVC-SVC requests and a second layer based on EU+SVC-SVC requests. Access control processing logic based on the second layer involves multiple calls by service proxy, such as (1) a call to the authorization engine service to obtain the access decision after obtaining the user attributes (including user credentials) and application object attributes from the orchestration system, (2) obtaining the authorization token from the service mesh control plane based on the access decision, and (3) including the authorization token along with the service request.

This section provides the justification for the various building blocks of the architecture for the authorization framework (e.g., the service mesh and NGAC-based ABAC model). It also highlights the scalability and flexibility of certain components such as proxy APIs and the NGAC authorization engine.

a. A service mesh is the right architecture for the enforcement of authorization policies since the components involved are moved out of the application and executed in a space where they can form a security kernel that can be vetted. b. Both types of authorization requests (i.e., SVC-SVC and EU-SVC-SVC) can be handled by a runtime infrastructure that involves the coupling of an orchestration platform control plane, service mesh control plane, and mesh data plane to the access control engine. c. The extensible API of the proxy can be used to integrate any authorization engine using the appropriate type of access control model. ABAC has been found to be one of the most flexible, scalable access control models because of its ability to incorporate any number and type of attributes associated with the subject, object, and environment. d. Performance requirements for the authorization engine are met due to the linear time processing speed of the graph-based, NGAC-based ABAC model. e. The flexibility outlined in (c) can be leveraged to incorporate models for both application and data protection by making data protection models as part of the authorization server.

Authorization can be enforced through a native structure (e.g., authorization policy) supported in the particular version of the service mesh or using calls to an external authorization server. The external authorization server can use any access control model and any representation of policy expressions (logical rules or acyclic graph representations), but the mediation of a request coming into the proxy can be performed in the following ways:

a. Each request is passed on to the external authorization server through the external authorization filter in the proxy, and the response from the authorization server is used for request mediation in the form of ALLOW or DENY. b. Prestored ACLs can be used in the proxy itself, generated by calls to the authorization server. If the authorization server uses an enterprise-wide access control model, an administrative API may be needed that will perform the function of mapping the enterprise resources to resources, users, and groups pertaining to the service served by its proxy to generate ACLs that are customized for the service.

Deployment guidance has been provided for an ABAC-based authorization framework for securing microservices-based applications using a service mesh. Background information on a reference platform for orchestration and resource management of microservices-based applications in terms of constituent building blocks and functional capabilities is outlined in Section 2. In the same section, the architectural layers and features of a reference platform for service mesh are described. Section 3 provides background information on ABAC and discusses two representational structures and associated functional architecture.

Section 4 provides the building blocks of the authentication and authorization framework – the set of recommendations for settings/defaults of those features of the service mesh that provide the operational assurances for applications, specifically for implementing authentication and authorization policies. The recommendations span mechanisms for supporting both end user and service level authentication and authorization policies. The minimal set of policy elements needed in authorization policies is also outlined.

The presence of a reference monitor concept in the authorization framework, the description of the supporting infrastructure for implementing the framework, the advantages the service mesh provides for implementation of an ABAC authorization framework, and the enforcement alternatives in proxies form the content for Section 5.

The list of all recommendations for deployment of an ABAC-based authentication and authorization framework for microservices-based application using a service mesh is given in Appendix A.

References

[1] Rose S, Borchert O, Mitchell S, Connelly S (2020) Zero Trust Architecture. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication

(SP) 800-207. https://doi.org/10.6028/NIST.SP.800-207

[2] Red Hat (2021) What is CI/CD? Available at https://www.redhat.com/en/topics/devops/what-is-ci-cd#:~:text=CI%2FCD%20is%20a%20method,continuous%20delivery%2C%20and%20continuous%20deployment

[3] Red Hat (2021) What is DevSecOps? Available at https://www.redhat.com/en/topics/devops/what-is-devsecops

[4] Chandramouli R (2019) Security Strategies for Microservices-based Application Systems. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-204. https://doi.org/10.6028/NIST.SP.800-204

[5] Hu VC, Ferraiolo DF, Chandramouli R, Kuhn DR (2018) Attribute-Based Access Control (Artech House, Boston USA).

[6] Chandramouli R, Butcher Z (2020) Building Secure Microservices-based Applications using Service-Mesh Architecture. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-204A. https://doi.org/10.6028/NIST.SP.800-204A

[12] Mell P, Shook J, Harang R, Gavrila S (2017) Linear Time Algorithms to Restrict Insider Access using Multi-Policy Access Control Systems. Journal of Wireless Mobile Networks, Ubiquitous Computing, and Dependable Applications 8(1):4-25. https://doi.org/10.22667/JOWUA.2017.03.31.004

[13] Ferraiolo D, Chandramouli R, Hu V, Kuhn R (2016) A Comparison of Attribute Based Access Control (ABAC) Standards for Data Service Applications: Extensible Access Control Markup Language (XACML) and Next Generation Access Control (NGAC) (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-204A. https://doi.org/10.6028/NIST.SP.800-178

[14] Agarwal G (2020) Enable Mutual TLS Authentication between your Kubernetes Workloads Using Istio (Medium.com). Available at https://medium.com/better-programming/enable-mutual-tls-authentication-between-your-kubernetes-workloads-using-istio-65338c8adf82

[15] Envoy (2021) External Authorization. Available at https://www.envoyproxy.io/docs/envoy/v1.17.0/intro/arch_overview/security/ext_authz_filter#arch-overview-ext-authz

[16] Envoy (2021) JWT Authentication. Available at https://www.envoyproxy.io/docs/envoy/v1.17.0/configuration/http/http_filters/jwt_authn_filter#config-http-filters-jwt-authn

[17] Hu VC, Ferraiolo DF, Kuhn DR, Schnitzer A, Sandlin K, Miller R, Scarfone K (2014) Guide to Attribute Based Access Control (ABAC) Definitions and Considerations. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-