inject: Add tap client identity to proxy injector environment variables

[kleimkuhler]

Feature Request

When proxies are injected, they should contain the tap client's TLS identity as an environment variable.

What problem are you trying to solve?

For #2676, a proxy's tap server must only accept incoming connections from the Linkerd tap client. We are currently able to compare an expected TLS identity with the identity of the incoming connection, but we do not know what the expected TLS identity of the tap client will be.

How should the problem be solved?

Upon proxy injection, the tap client's identity should have been verified; this is assuming the user did not pass --disable-identity to the original install.

What do you want to happen? Add any considered drawbacks.

We should consider the --disable-identity flag. In this scenario, the environment variable should be unset or absent; I'm not sure how we do this right now, but it should be consistent with other optional environment variables. The responsibility of handling an unset/absent tap client identity will rest on the proxy itself.

Any alternatives you've considered?

The tap client's identity can not be passed through in a dynamic way. I believe this needs to happen at inject time and used as part of the proxy's configuration, but I'm open to other suggestions.

How would users interact with this feature?

This is not user facing.

[olix0r]

Small correction: I think you specifically mean that they contain a Tap Client identity. The fact that this is (or was) the controller is an implementation detail of the control plane. In fact, we may want to support a list of allowed identities to support migrations or other integrations.

[kleimkuhler]

Oh yes thanks for pointing that out!

[ihcsim]

Does this include proxies in the control plane? These proxies are injected by the linkerd install command, without going through the proxy injector (as it doesn't exist yet).

Also, is the TLS identity equivalent to the issuer's name, CN (i.e. identity.linkerd.cluster.local)?

[kleimkuhler]

Yes so we do use tap in the Linkerd namespace and these pods should authenticate clients the same way.

I'm not familiar right now with when the tap service's local identity becomes ready during install; @dadjeibaah has a PR open right now to move it into its own pod.

If we are not able to rely on having the tap service's identity ready when injecting other Linkerd proxies, there may be more design discussion here.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

[kleimkuhler]

Closed in #3155