Service identity injection to request payload

[rucciva]

Summary

A service might implement a custom Accounting logic. Meanwhile in service mesh scenario, it is preferred to delegate Authentication and Authorization to the data plane, making the receiving service unaware of the caller identity. Thus it would be preferable if the caller identity can be made available to the receiving service, .e.g through HTTP header injection.

Steps To Reproduce

Additional Details & Logs

• Version: 1.0.1
• Error logs: -
• Configuration: -
• Platform and Operating System: -

[subnetmarco]

This would be quite simple to implement, I would assume (at least for HTTP requests). We could be returning two headers:

• X-Kuma-Forwarded-Client-Cert, with the full Spiffe entry.
• X-Kuma-Forwarded-Client-Service, with the service name only.

And perhaps:

• X-Kuma-Forwarded-Client-Zone, with the service zone name only.

[slonka]

Just a couple of things to keep in mind when implementing this:

If you want the full spiffie entry you can use https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/network/http_connection_manager/v3/http_connection_manager.proto#extensions-filters-network-http-connection-manager-v3-httpconnectionmanager-setcurrentclientcertdetails and set the type to URI (side note: from my experience developers do not want the full spiffie entry, and making everyone parse that themselves is pointless).

For the service name you have to manually extract it. The SAN URI part is available via Lua scripts, an example usage is here: https://github.com/allegro/envoy-control/blob/master/envoy-control-core/src/main/resources/lua/ingress_client_name_header.lua#L12 , but make sure you use Envoy version higher than 59e29685d33bd730c76ccb3b8383b666c0942523 (a couple of commits after 1.16.0 edit: 1.16.1) otherwise you’ll encounter Envoy SEGFAULT after a couple of requests pass through that script (details here: envoyproxy/envoy#14092).

Kuma identifies services by SAN URI: spiffe://{mesh}/{service} so additional question to @subnetmarco - by “service zone” name only you mean the first part of the URI “{mesh}“ right?

[nickolaev]

Thanks for the pointers @slonka. We have already adopted envoy 1.16.1, so that should not be a problem.
About your last question, I guess @subnetmarco referees to the kuma multi-zone deployments, where we have distributed/hybrid deployments. So a zone would be something like dc-us-east or dc-eu-north.

[slonka]

@nickolaev I'm sorry I was mistaken v1.16.1 was released 2020-11-20 18:43:35 -0800 and that fix was merged 2020-11-23 09:54:37 +0100 so you still need to upgrade if you want to use that feature.

[jewertow]

I will work on this issue.

[jewertow]

@rucciva you can get service identity from the header x-forwarded-client-cert. This header has the following content:

X-Forwarded-Client-Cert By=spiffe://{mesh}/{service};Hash={hash};URI=spiffe://{mesh}/{service}

So you can parse this header, get URI and retrieve name of the service.

I will come back to this feature the next week and I will implement headers proposed by @subnetmarco.

@slonka thank you very much for your hints. They were very helpful.

[github-actions]

This issue was inactive for 30 days it will be reviewed in the next triage meeting and might be closed.
If you think this issue is still relevant please comment on it promptly or attend the next triage meeting.

[github-actions]

This issue was inactive for 30 days it will be reviewed in the next triage meeting and might be closed.
If you think this issue is still relevant please comment on it promptly or attend the next triage meeting.

[rohank2002]

I see that that the pull request was merged, is this issue resolved? I was testing internal mtls using Kuma. I used a podinfo deployment for getting the headers from the request. I couldn't see the XFCC header.

[lahabana]

I think the issue is still open because the implementation was never completed. @jakubdyszkiewicz do you have more ctx?

[github-actions]

This issue was inactive for 30 days it will be reviewed in the next triage meeting and might be closed.
If you think this issue is still relevant please comment on it promptly or attend the next triage meeting.

[slonka]

The issue is still open because this was not merged: #2158 (comment) right?

[scottslowe]

+1 for finishing up the implementation of this functionality

[slonka]

For these headers to be injected appProtocol needs to be set to http or grpc https://kuma.io/docs/1.7.x/policies/protocol-support-in-kuma/#protocol-support-in-kuma

(edited)

[github-actions]

This issue was inactive for 90 days. It will be reviewed in the next triage meeting and might be closed.
If you think this issue is still relevant, please comment on it or attend the next triage meeting.

[whiskeysierra]

For these headers to be injected appProtocol needs to be set to http https://kuma.io/docs/1.7.x/policies/protocol-support-in-kuma/#protocol-support-in-kuma

Shouldn't grpc work as well?

[slonka]

Shouldn't grpc work as well?

you're right, it just needs to be different than tcp

[github-actions]

This issue was inactive for 90 days. It will be reviewed in the next triage meeting and might be closed.
If you think this issue is still relevant, please comment on it or attend the next triage meeting.

[github-actions]

This issue was inactive for 90 days. It will be reviewed in the next triage meeting and might be closed.
If you think this issue is still relevant, please comment on it or attend the next triage meeting.

[github-actions]

This issue was inactive for 90 days. It will be reviewed in the next triage meeting and might be closed.
If you think this issue is still relevant, please comment on it or attend the next triage meeting.

[github-actions]

This issue was inactive for 90 days. It will be reviewed in the next triage meeting and might be closed.
If you think this issue is still relevant, please comment on it or attend the next triage meeting.

[slonka]

AFAIK this is solved (with the full entry, clients have to extract name manually), you just need to make sure you mark the app with protocol http/grpc. Closing, if something does not work please reopen.