Skip to main content

Service-to-Service Authentication

Context​

Microservices are being adopted. Microservices communicate with each other to exchange data and information at runtime. All microservices within the infrastructure are trusted There is no authentication and authorization between microservices.

Problem​

  • Attackers can manipulate all microservices by compromising only one microservice instance.

Solution​

Implement service-to-service authentication and authorization.

Instead of just trusting other microservice instances, validate their authenticity and priviledges.

LN41 and LN44 suggest to adopt MTLS for mutual microservice authentication. Coarse-grained authorization can be implemented by using certificates as well LN44 to validate if a microservice is allowed to call another one. More fine-grained authorization is supported by generic established authorization frameworks like OAuth 2 LN41.

Maturity​

Proposed, evaluation required.

Sources of Evidence​

LN41:

  • Trust is important dimension of safety
  • Need to consider authentication and authorization issues when services communicating with each other
    • MSA should verify authenticity of every service
      • Compromised service can influence other services, e.g., by taking up most of resources or interfering with the network
    • Service needs to find out if message is suprious and source has valid authority
    • Microservice has to be authorized to access users' resources / exchange data
      • Need to secure privacy information like a user password
      • OAuth: does not require user password
  • Deployment to distributed computing environment => ineffective access control mechanisms
    • careful delegation of access rights can limit attackers from damating system
    • LDAP as example
    • Grid Security Infrastructure for private key protection and communication encryption
    • Community Authorization Service model for distributed adminisration
    • OAuth to protect REST APIs
    • OpenID Connect as authentication layer on top of OAuth
    • Thanh's framework
      • OAuth 2 and ABAC
      • centralized security management
    • => OAuth as solution, but danger of information breach; Cheung et. al. present adoption of OAuth 2 fixing some of the flaws
  • Present their "ideal solution"
    • contains Spring Cloud Security framework for authentication and authorization among other technologies
    • Microservices use it for communication with each other
    • To secure permission: HTTP digest authentication or public and private key encryption
    • Or integrate Oauth 2 with Spring cloud Security framework
    • Spring cloud security framework as ideal technology
      • provides access control capabilities
      • filters for request intersection for authentication and access control
      • encapsulates complex security config
      • can integrate OAuth2

LN42:

  • need for authentication mechanisms for data flowing between microservices

LN44:

  • If internal services just trust the callee, one single compromised microservice suffices to manipulate all other nodes
    • e.g., by issuing arbitrary malicious requests (confused deupty problem)
    • eardrop, insert, modify data in transig
  • Security = trade-off between minimizing budget and covering more attack vectors
    • Assumption: hardware and cloud providers can be trusted, as well as Deployment
    • => model that security engineers are willing to accept in practice
  • Mutual authentication of services using MTLS
    • using self-hosted Public Key Infrastructure
    • Examples: Docker Swarm, Netflix
      • Netflix uses long-lived credentials to regularly retrieve short-lived credentials
    • does not adrress servuce authorization
  • Inter-service authorization based on certificates
    • only microservices co-dependent by design should be allowed to call each other
    • can reuse PKI and MTLS to provide basic s2s authorization
    • certificate per microservice type => sign certificates of all instances of the same type
  • Propose microservice security framework
    • CA service as part of PKI infrastructure to enable MTLS between microservices
    • Reverse STS behind a user authentication service to generate JWT tokens per user request
    • Evaluation experiment: 11% performance reduction deemed as acceptable

LM43:

  • Context: SLR findings about microservices in DevOps
  • S10 presents ARCADIA framework: enable security and privacy across microservice lifecycle by multi-vendor security solutions
    • FWaas, OAuth 2

LM47:

  • Context: SLR with tactics to achieve quality attributes
  • Security: authentication between services
    • Motivation: containers/VMs => need to immitate security of monolith
    • trustworthy ensemble requires communcation channels to be secured
  • Key exchange-based communcation
    • key associated with verifyable roles
    • usually symmetric encryption scheme
    • names some encryption algorighms: HMAC
      • encrypts messages with key
    • only receivers know encryption key (AES) and integrity key (HMAC) to decript message
  • Client certificats on transportation layer (TLS)
    • for REST HTTP: HTTPS to authenticate both sides of communication channel through server and client certificates, eg X.509
    • names some TLS implementatino alternatives: (Federated/Local) Attested TLS,
  • Federated identity extends host-authenticated TLS
    • in-band authentication options
    • allows to use identity management system to store identity of users for auth
    • usually adopt trusted third party
      • issues tokens, eg JWT
      • implemented as separate service or SSO framework
      • examples: OpenID Connect, SAML, OAuth2, Shibboleth
  • Key exchange might require key management
  • Trade-off between performance and security