Skip to main content

Encrypt Service-to-Service Communication

Context​

Microservices are being adopted. Microservices communicate with each other to exchange data and information at runtime. This communication is not encrypted.

Problem​

  • Attackers can intercept communication and read the transmitted data.

Solution​

Secure the communication channels between microservice instances with encryption, e.g., via TLS encryption.

Interviewees B explained that most projects communicate openly without encryption behind their API facade. Another interviewee elaborated on their current endeavour towards secure communication channels between microservice instances using service meshes like Istio or Linkerd. The use of such sidecars appeals by providing communication security and network policies out of the box.

Maturity​

Proposed, to be evaluated.

Sources of Evidence​

L40:

  • Need proper cryptographic schemes for data protection at rest and in motion
    • access and integrity control to exchanged messages

L53:

  • Containers can force traffic thru VPN to encrypting all data

L55:

  • Securing communication as piece to the security and privacy puzzle
    • without secure channel, cannot build trustworthy authentication and authorization
    • MAYA platform employs SSL and TLS for communication and data storage

LN41:

  • Context: complex communication
  • risk: intercepted data, but also competitors might infer business operations from message data
  • need for data encryption, access control, safe storage for backup data
  • common practice: symmentrical keys to encrypt tennants' critical data
    • layer on top: async encryption of symmetric keys
    • esp. important for mission critical data and data privacy, esp. if tenants share the same database tables
  • encryption widely used method to ensure security and privacy of data in microservice communication
    • different encryption mechanisms
  • likely that weakest spots are attacked => secure endpoints with HTTPS and enforce HTTPS
  • Propose their "ideal solution"
    • Data mixed encryption between microservices
    • AES and RSA => double layer protection of data with less impact on communication efficiency
    • intercepted data cannot be deciphered without the shared key

LN42:

  • need for communicatin encryption to secure data flowing between microservices

LN44:

  • Tokens must be sent over protected channel, e.g., TLS / SSL
    • otherwise: token can be intercepted and reused within validity period

LM43:

  • Context: SLR findings about microservices in DevOps
  • S46 suggests combination of standard cryptographic primitives
    • HashChangeEvent, MAC functions for auth encryption
    • to provide high level of security and flexible authentication

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
  • Key exchange might require key management
  • Trade-off between performance and security

Interview A:

  • Current challenge: encrypt communication of containers among each other
    • assumes challenge for all players right now
  • Solution: service mesh
    • e.g. Istio, based on Envoy
    • is a kubernetes sidecar, each container communicates of localhost with Envoy container
    • Envoy establishes secured connection with dependency
    • Trend away from istio to LinkerD (will probably choose that, currently experimenting with it)
  • Service mesh adds to tracing topic, much more fine-granular
    • also to network policies
    • also to encrypted communication
  • Is the next big chunk of knowledge they are building up
  • White-listing of communication partners => as soon as activated, might blow up local development setup
    • probably requires some iterations to get that solved

Interview B:

  • Standard approach: secure to outside but communicate openly within (but with tokens)
  • Gateway as pivot point