Today at KubeCon EU in Barcelona, Microsoft introduced a new specification, the Service Mesh Interface (SMI), for implementing service mesh providers into Kubernetes environments.
The Service Mesh Interface (SMI) is a specification for service meshes that run on Kubernetes. It defines a common standard that can be implemented by a variety of providers. This allows for both standardization for end-users and innovation by service mesh providers. SMI enables flexibility and interoperability.
We partnered with Microsoft to support the creation of this controller and this blog will explain how it can be used to set HashiCorp Consul Connect intentions within Kubernetes clusters.
Microsoft’s Service Mesh Interface is a series of Kubernetes controllers for implementing various service mesh capabilities. At launch, SMI will support four primary functions:
At launch, HashiCorp Consul will support the Traffic Access Control specification, with possible integrations for the others in the future.
One of the custom resources defined by SMI is the TrafficTarget resource, developed by us in collaboration with the Microsoft team to assist with the challenge of securing service-to-service traffic. This resource enables the user to define Consul Connect intentions in a Kubernetes custom resource (CRD) and manage them through
Terraform, rather than having to configure them directly through Consul. This enables developers to ensure that newly deployed applications have a secure connection to resources through a single workflow. Here is an example of how to configure this controller:
Assuming you have two services running in Kubernetes: a dashboard that shows the current value and a counting service that increases the count with each request. Both are configured to communicate via the Envoy sidecar proxy.
By default, Consul Connect denies all traffic through the service mesh. In order for traffic from the dashboard to be able to reach the backend service, you need to define an intention that allows traffic from the dashboard to the backend service.
You can create this intention using the TrafficTarget CRD below, store it as
intention.yaml and apply it using
kubectl apply -f intention.yaml.
--- apiVersion: specs.smi-spec.io/v1alpha1 kind: TCPRoute metadata: name: counting-tcp-route --- kind: TrafficTarget apiVersion: access.smi-spec.io/v1alpha1 metadata: name: counting-traffic-target namespace: default destination: kind: ServiceAccount name: counting namespace: default sources: - kind: ServiceAccount name: dashboard namespace: default specs: - kind: TCPRoute name: counting-tcp-route
This will create an intention in Consul that allows traffic from the dashboard service to the counting service.
With this intention created, the dashboard will be able to show the current value retrieved from the counting backend.
Information about Microsoft’s SMI can be found on their home page and Github repo. By leveraging this new resource, users will find it easier to utilize Consul Connect’s capabilities inside of their Kubernetes environments. Outside of Kubernetes environments, Consul’s service mesh capabilities can also be extended to hybrid or multi-cloud environments, for more complex application deployments.
If you would like to experiment with SMI and Consul, we have built an experimental Kubernetes controller which can be found in the following repository: https://github.com/hashicorp/consul-smi-controller
For more information about this and other features of HashiCorp Consul, please visit: https://www.consul.io.
Consul API Gateway 0.4 introduces support for the new beta version of the Kubernetes Gateway API and HTTP path rewrites.
This release enhances a number of features in Consul while adding such new features as a Consul on Kubernetes CNI plugin and a beta version of cluster peering.
A service mesh like HashiCorp Consul can be an essential part of applying zero trust security principles to modern, complex, Kubernetes deployments.