Cloud Microservice Security

John

Monolith Architecture Security Controls

Below is a sample traditional monolithic architecture with various security controls.

 

Microservices

Microservices are an architectural approach.

  • Decouple system into small, independent services
  • Use well defined service APIs
  • Each microservice is easy to change and deploy independently
  • They fit naturally with containers – one microservice per container

Consider the following microservice architecture and the possible attack surfaces. Certain endpoints can be open/exposed, perhaps without authentication.

Below is example of Netflix’s topology

Microservice Tradeoffs

Some trade offs to consider when taking microservice approach.

  • Increased runtime complexity (lots of moving parts)
  • Increases runtime latency
  • Failure handling chained runtime dependencies may occur
  • Cross cutting changes are harder to understand
  • Polygot technology and technical debt can build up
    • Each team uses their own language, framework, etc.
    • No consistency between the microservices
  • Testing can be difficult. May require some tests to happen in production
  • Difficult to monitor

Microservices security challenges

  • Potential attack surface can be large
  • Cannot depend on perimeter
  • APIs are susceptible to DDOS attacks
  • Polyglot technologies increase difficulty in security
    • Each tech stack requires different security tools, features
  • Static analysis tools are not designed for microservcies
  • Forensics, monitoring and incident response is difficult
    • How do forensics on cattle? Something only last few minutes?

Security best practices – API Gateway

API Gateways provide a single point of entry for all clients

  • They provide consistent authentication/authorization controls
  • API gateway proxy/route requests to the appropriate service
  • They can combine multiple calls to microservices into a single API call
  • Package different data for different clients
  • Integrates with mutliple protocols (filesystem, SMTP, etc)

Some benefits of using API gateways

  • Insulates the client
  • Reduces number of roundtrips
  • Simplifies logic for client
  • Secure gateway for all microservice requests

Some cons of using API gateways

  • Higher complexity
  • Longer time for roundtrip

Microservices Authentication Options

  • Security Token Service (STS)
  • Identity Federation
    • SAML 2.0
    • ADFS
    • Windows AD
  • Web Identity Federation
  • Cognito User Pol

AWS Security Token Service (STS)

  • Interacting with all AWS services requires API requests to be signed with AWS access keys
  • Longterm security credentials should never be hardcoded or deployed
  • STS allows applications/services to request temporary security credentials mapped to an IAM role
    • Instance profile roles assuming idenitty
    • Enterprise authN via SAML federated
    • Public authN via OpenID Connect (OIDC) federated identity
  • Some of the API commands for temp access tokens:
    • AssumeRole = allows IAM users to temp assume role
    • AssumeRoleWithSAML = temp creds for federated users
    • AssumeRoleWithWebIdentity = temp creds for federated users authN through OIDC
    • GetFederatedToken = allows federated users to temp assue an IAM role
    • GetSessionToken = allows untrusted users to obtain temp creds

Identity Federation

Use of Security Assertion Markup Language (SAML) 2.0

  • Avoid creating IAM user for all users/apps
  • Allows users to authN against organization’s IDP
  • SAML assertion is sent to STS to obtain temp security creds
  • Enables SSO
  • Below shows how user starts with corporate IDP and swaps it for an STS token as they enter AWS

Web Identity Federation

Basically this is OpenID Connect (OIDC)

  • Avoid creating an IAM user for external user
  • Allow authN through external IDPs like Amazon, Facebook, Google
  • An OIDC provider gives authN token which is passed to STS to obtain temp cred on that side.
  • This is usually done through a redirect from STS

Some major IDPs vendors

  • Ping Identity = enterprise level IDP for SSO, MFA, API access, directory services
  • ForgeRock = enterprise level IDP, API gateway, directory services
  • Okta = Enterprise level identity, mobile and SSO
  • AuthO = Developer focused authN  (acquired by Okta)
  • Stormpath = developer focues (acquired by Okta)

Authorization and Access Control

Microservices often verify user authZ and access control with JSON web tokens (JWT) provided by the IDP. JWT specification defines the following format.

In March 2015 security researcher doscovered a vulnerabilitty in sveral JWT library. He found that attackes could control the algoithm value in the header. Changing the algorithm to “None” and the signature to empty bypassed the signing verification

JWT Best Practices

  • JSON web signature (JWS) signs the header and payload using an HMAC private key
  • The signature verification must ignore the header’s algorthim
  • JSON web encryptioni (JWE) is the only way to ensure confidentiality of all claims
  • Expirtation using creation and expiration
  • Check the audiance (aud) claims to ensure the JWT is meant for that groupss

Microservices/Containers use of TLS and example of PKI Deployment

All nodes authN over HTTPS with client certificate authentication

 

There are tools now that automatically manage these internal certificates for you. This is known as a service mesh.

  • Sidecar proxy (Envory) controls traffic between services
  • Load balancing between services
  • Traffic control for routing, failover and fault injection
  • Metrics, logs, tracing
  • Vendors:
    • Istio, LInkerd, Consul, App Mesh

 

 

 

 

 

 

References

eof