Mini-Book: Securing Microservice APIs

“Securing Microservice APIs: Sustainable and Scalable Access Control” by Matt McLarty, Rob Wilson, and Scott Morrison

• Identification: “Service consumers and intermediaries must be able to send API request messages that include multiple identities along with optional attributes that detail those identities, and they must be able to accept API requests that include multiple identities and their attributes.”
• Authentication: “API requests may be authenticated through included credentials, asserted claims (e.g. a token), trust relationships, or a combination of these methods.”
• Authorization: “Any application component–service or intermediary–that authenticates an identity may make an authorization decision based on the combination of the identity, its attributes, and the request context.”
• Accountability: “It is important to audit system affected by API requests in order to provide forensic details for intentional or unintentioned system breaches.”
• “Localhost isolation simplifies applications because they can trust all senders. It allows us to associate services with specific ports, approximating the traditional TCP and UDP security model bindig wellknown ports to specific applications.”
• “But this model does nothing to identify client applications (source ports are ephemeral and assigned by the network stack) and assumes that all processes on the OS are equally trustworthy. And it tells us nothing about users associated with a client entity–for that we need to move up the stack.”
• “Network segmentation, using clever combination of physical switches, routers and firewalls, is one of the foundation elements of computer security. By combining trusted entities into a private segment, developers can focus on application logic, not access control. But this free ride comes at a cost, as any failure in the segmentation scheme put every entity at risk.”
• “The real problem with network segmentation comes with size. As networks becomes more complex, the rules governing zone membership becomes difficult to maintain. And as the number of zones and hosts increase, so too doe sthe attack surface.”
• “all APIs shoudl use SSL/TLS everywhere.”
• “The Secure Production Identity Framework For Everyone (SPIFFE) attempts to simplify microservice authentication and secure network configuration. SPIFFE provides a developer-friendly means for dealing with X509 certificate-based identities in a microservice network.”
• When to use network segmentation
  • “When you trust the physical security of the server and netowrk infrastructure”
  • “When you trust the infrastructure isolation mechanism and process”
  • “When you trust every entity on the network segment”
• “But traditional web sessions have limitations. The Session Identifier binds back to an act of authentication, and so it acts as a proxy for a user’s primary authentication factors. This is why session hijacking is such an effective attach. Once an attacker acquires a session ID, they are able to do anything that valid credentials would permit.”
• “SAML, however, is not a good solution for APIs or microservices. It is a complicated technology, relying too much aon centralized, formal trust administration and expensive, enterprise-oriented infrastructure.”
• API keys: “It is useful for rough usage tracking and traffic management, but always remember it could be spoofed.”
• “OAuth allows users to delegate access between distributed applications. It is not an authentication protocol, which proves a user’s claim to an identity. It is an authorization protocol that lets a user (the resource owner) grand an app (the client) access to an API (the resource) on their behalf. This access is for a limited time and with limited scope.”
• “OpenID Connect is an authentication layer built on top of the OAuth framework. OAuth is concerned only with authorization, making no attempt to define how authentication take place. OpenID Connect takes this on, providing flows to authenticate an end user and provide claims back to a relying party.”
• “Many OAuth implementations make useof opaque access tokens, sometimes called a by-reference token. Usually these are randomly generated identifiers, infeasible for an attacker to guess, that index state on a centralized server. The resource must validate this with the issuer.”
• “But dereferencing a token can be expensive, and centralization alwasy creates a bottleneck that could limit scalability and reliability.”
• “The alternative is to use a transparent token that can be interpreted at a local decision point. This is called a by-value token. Architectures with transparent tokens scale well by removing the central validation bottleneck. Each resouce can also apply locally managed policy when interpreting a token; this can be valuable when corssing organizational or geographical boundaries. OpenID Connect’s ID Token is a transparent token.”
• “JSON Web Token (JWT) is a simiple, JSON-based packaging format for exchanging claims. The claims can be anything you can represent in JSON; JWT adds only a formalized header and body, a signing mechanism (JWS), optional encryption (JWE), and a simple web encoding. The ID Token form OpenID Connect is a JWT.”
• “Authoritative claims are the basis of access control models like attribute-based access control (ABAC). ABAC shifts authoriztion from individual identity-centric decisions (Bob is allowed access to the printer) to attribute-centric rule set (All systems on the third floor can access the third-floor printer). This is a powerful technique to apply to microservices, which have a need to restrict access but also promote re-use by many different (and continuously changing) sources.”
• When to use tokens
  • “You need to authenticate and authorize users and applications.”
  • “Your trust needs to cross boundaries, which might be organizational, geographical, application, or virtual.”
  • “You can tolerate ceremony between applications and users.”
  • “You have the infrastructure to faciitate the token exchange.”
• “Always use OAuth 2.0 when authorizing an external client to edge-of-network endpoints. Tokens can be opaque in this use case. For internal hops, use Authen with transparent JWT tokens to cross boundaries between network zones. Use an intermediary capable of applying local policy interpretation on tokens to enforce access control across the boundary.”
• “AWS IAM does not use OAuth 2.0, JWT, or OPenID Connect.”
• “Istio is a service mesh platform for microservices. it focuses on traffic management, security policy enforcement, and telemetry. Istio is an open-source effort led by Google, IBM,a nd Lyft.”
• Domain Hierarchy Access Regulation for Microservice Architecture (DHARMA)
  • “Inner domains that are groupings of the organization’s most granular services”
    • “Lastly, the inner-domain trust mechanism will have the strongest optimization bias towrd runtime performance as opposed to strictness of authentication. Network isolation in the form of VPC or host collocation is feasible at this level. Nonetheless, JWT’s may still be passed on API requests in order to maintain system accountability and observability.”
  • “An outer domain made up of the organization’s corse-grained services that are most likely to be re-used across the organization, and by external entities”
    • “Digital certificate-based trust is a proven, scalable option for establishing trust. In fact, JSON Web tokens signed using an organization-issued certificate can be used to preserve end-user identity as well as to assert the identity of the service makign the API request.”
  • “A region outside the organization’s control that may include external entities who will make API requests to the organization’s externally published services”
    • “Following the lead of the open web, OAuth 2.0 makes sense here, especially in conjunction with an opaque access token format that cannot be derived by external attackers.”
• “It is expected that the JWTs used inside the domains will have a short expiry timie (less than an hour). Depending on scale and sensitivity, they may be issued for single use.”
• See: https://www.microservices.com/talks/dont-build-a-distributed-monolith/

Advertisement