Kuma service mesh — Data plane token lifecycle
I generally sift through community slacks of open source tools, to see if i can help answer some questions. I stumbled upon this question about validation of Kuma data plane token at https://kuma-mesh.slack.com/archives/CN2GN4HE1/p1659536026513639 I was intrigued and wanted to dig through the Kuma code.
NOTE: This blog is just me thinking out loud while browsing through code at https://github.com/kumahq/kuma. It does not guarantee technical accuracy and is just a code pointer for fellow kumans.
I would like to thank folks at @konghq for open sourcing this great software.
So the first thing i know about data plane token is that every Data plane proxy needs to present a token to zonal CP (control plane) to get itself registered to the zone.
From official doc —
The data plane proxy token is a JWT token that contains:
Mesh to which data plane belongs (required)
The name of a data plane proxy (optional)
List of tags that are permitted to use (optional)
Expiration date of the token (required, 10 years if not specified)
The Data plane proxy token is signed by a signing key that is autogenerated when Mesh is created. Tokens are never stored in the control plane, the only thing that is stored are signing keys that are used to verify if a token is valid. The signing key is RSA256 encrypted.
# Example command to get token valid for all dp's in mesh
$~ kumactl generate dataplane-token --mesh mymesh --proxy-type dataplaneI also knew that the token generated is a jwt token which is like data palne proxy verifying its identity with the zone CP.
Some important fields are Mesh , Name and Tags . Also the exp — token expiry field. Default is 10 Years validity.
Since i didn’t have idea on server side, i started with what i knew — the cli command.
- Generation
The code layout of kumahq always felt little easier to grasp. My favourite folders are app and pkg . App folder has all the tools we generally use, and interesting one for us is app/kumactl . It uses cobra package so i know the command layout. so went to kuma/app/kumactl/cmd/generate/generate_dataplane_token.go I saw that the client uses client.Generate which is essentially a http client which does a POST call to /tokens/dataplane endpoint.
As per doc, in multi-zone mode, the token can be created at both global level and zone level but Signing key rotation or token revocation should be performed on the global control plane.
I think in a logical way, tokens need to be created at global CP, because meshes can be part of multiple zones and in that case, logic feels token should be valid across zones 😆 Although in below section, we will find out that this doesn’t matter (hint: Token is synced).
2. Validation
So whenever a mesh gets created, it also ensures there is an associated data plane token signing key associated to this mesh.
But the actual registration happens between DP proxy and Zone CP right? so Global and zones sync this signing key using kds (kuma discovery service). Reason why generating token at both zone and global works.
As per doc, generated dp tokens aren’t stored but are just validated through signing key. so whenever data plane proxy registers itself with zone CP, it authenticates the jwt token.
3. Revocation
From doc at https://kuma.io/docs/1.6.x/security/dp-auth/#token-revocation
Kuma does not keep the list of issued tokens. Whenever the single token is compromised, we can add it to revocation list so it’s no longer valid.
Every token has its own ID which is available in payload under
jtikey.
So as part of validation, token is checked if it is not in the revoke list.
Happy meshing 🖖
