Service Mesh Interface and SPIFFE

As the service mesh concept continues to evolve, a Service Mesh Interface (SMI) specification is emerging, which provides interoperability between different service meshes. Kubernetes has already made network and storage extensible through the Container Network Interface (CNI) and Container Storage Interface (CSI) specifications. In the same spirit, the SMI specification, though new, has started to gain traction from different service mesh providers.

This chapter will introduce you to the evolving SMI specification and the SPIFFE specification, which provide secure naming conventions for the services running in a Kubernetes environment.

In this chapter, we will cover the following topics:

• SMI
• SPIFFE

SMI

The SMI is a specification standard for portable APIs for interoperability between service mesh providers. Brendan Burns proposed the SMI in May 2019 for a common standard along the lines of CNI, CSI, and OCI, which are the abstraction interface standards for network, storage, and containers for Kubernetes.

As service meshes continue to gain momentum in order to provide an infrastructure layer on top of modern cloud-native applications, the need for a SMI specification is arising. Gabe Monroy announced the launch of the SMI in May 2019 with the launch of an open source project (https://smi-spec.io/) in collaboration with Istio, Linkerd, and Consul.

SMI intends to support tooling through an abstraction layer for frameworks such as Weavework's Flagger (https://github.com/weaveworks/flagger) and Rancher Labs' Rio (https://rio.io and https://github.com/rancher/rio...

SPIFFE

Secure Production Identity Framework for Everyone (SPIFFE – https://spiffe.io) was inspired by a few brilliant engineers due to their need to remove application-level authentication and network-level access control configuration. Joe Beda, one of the creators of Kubernetes, was the original author of the SPIFFE specification.

SPIFFE started as open source in 2016 for securely identifying software systems in dynamic and heterogeneous environments. It is mainly about establishing trust in a complex distributed environment where workloads are dynamically scaled and scheduled to run on any node in a cluster. The workloads using SPIFFE identify themselves with each other by looking at URIs such as spiffe://trust-domain/path, which are defined in a Subject Alternative Name (SAN) field in X.509 certificates.

SPIFFE's runtime environment is called the SPIFFE Runtime...

Summary

In this chapter, we learned how the service mesh is evolving and that the SMI is in its infancy. It is worth mentioning that the SMI, in terms of standards and abstraction, plays an important role for different service providers so that they can use a common standard. We also covered SPIFFE as a specification, which provides a secure naming convention for the workload so that it can be run in a zero-trust network. Istio has implemented SPIFFE through its control plane to provide a security infrastructure where a certificate's time-to-live could be as small as 15 minutes and maintain the PKI as a self-service model.

From this point on, we'll look at each of the different service mesh implementations. However, before we do that, we will build a demo environment so that we can practice using each of the service meshes on our own Windows laptop or Apple MacBook...

Questions

1. SPIFFE is a specification and not a toolset.

A) True
B) False

2. SMI is an alternative to service mesh providers.

A) True
B) False

3. Only Istio and Consul use SPIFFE at the moment.

A) True
B) False

4. Istio does not use SPIRE, but it has its implementation.

A) True
B) False

Further reading

• Hello Service Mesh Interface (SMI): A Specification For Service Mesh Interoperability, Monroy, Gabe, Open Source Blog, 2019: https://cloudblogs.microsoft.com/opensource/2019/05/21/service-mesh-interface-smi-release/
• Microsoft introduces Service Mesh Interface (SMI) for interoperability across different service mesh technologies, Packt Hub, 2019: https://hub.packtpub.com/microsoft-introduces-service-mesh-interface-smi-for-interoperability-across-different-service-mesh-technologies/
• Introduction To Service Mesh Interface (SMI), Brendan Burns At Qcon New York, Penchikala, Srini, Infoq, 2019: https://www.infoq.com/news/2019/07/burns-service-mesh-interface/
• Weaveworks/Flagger, GitHub, 2019: https://github.com/weaveworks/flagger/blob/master/docs/gitbook/tutorials/flagger-smi-istio.md
• Introducing Rio – Containers At Their Best, Shepherd, Darren, Rancher Labs,...