provide Service-to-Service authorization

[cypherfox]

Feature Request

What problem are you trying to solve?

Eliminating the need for any authentication and authorization in application micro services. As linkerd2 already has fairly strong identity management infrastructure for automatic TLS, it seems a good starting point.

How should the problem be solved?

By having the proxy request authorization (authz) from a service (e.g. an OPA wrapper), caching the for a TTL returned with the authz result.

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

Deny access to the target service if the identity does not comply with a pre-set policy.
For an initial prototype a whitelist of identities per service would be sufficient.

The request to the authz service may cause latency spikes, especially if the service is unavailable.

Any alternatives you've considered?

Building good Authz and Authn code in every micro service. This has never the level of quality that I would aim for.

How would users interact with this feature?

By configuring the authz service. The method and complexity of it would depend on the type of the authz service.

[cypherfox]

I have had a look at the traffic access control part of the SMI spec, as recomended by @grampelberg. The definition is covering my intended use case fine.
(see: https://github.com/deislabs/smi-spec/blob/master/traffic-access-control.md)
While this issue is more focussed on getting authz data to the proxy, being able to define the policy as CRD would be very welcome.

Since we are looking at using other policy engines like OPA, it would be usefull if the SMI CRDs where not only way to set authz policy.

[kubaj]

It would be nice to support external authorization that works similar to envoy's external authorization filter. This is useful when you run OPA as an authorization engine in a sidecar.

Communication flow:

Client          Proxy             Authz container       Service
    |---------> |                                          |
    |  1. Req   |---------------------> |                  |
    |           |    2. Authz request   |                  |
    |           | <---------------------|                  |
    |           |  3. Authz decision    |                  |
    | <---------|                       |                  |
    |  4a. 403  |                       |                  |
    |           |----------------------------------------->|
    |           |         4b. Service request              |
    |           |<-----------------------------------------|
    |           |         5. Service response              |
    | <---------|                       |                  |
    |  6. Resp  |                       |                  |

More details can be found also 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.

[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.

[cypherfox]

Update to the spec doc: https://github.com/servicemeshinterface/smi-spec/tree/master/apis/traffic-access/

[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.

[jgarces21]

I think this one is related to #2746

[cypherfox]

Hmmm... not as originally written, since Network Polices (NP) and client authentication approach restricting access from two different angles. IMHO The former is more like a machine based (think NFS v3) restriction, while the latter identifies different users (human or machine) and assigns permissions.

I hope SMI is comming soon, but do not doubt the correctness of @grampelberg's observation on most people only needing NPs

[glenjamin]

Is this actually wontfix?

I've been trying to find an issue I can subscribe to for future Access Control work, but so far i've only found #4647 and this one.

[olix0r]

This is planned for stable-2.11 (we're currently working on stable-2.10). This has mostly been blocked on extending mTLS to cover all meshed communication. In 2.9 we added mTLS for most TCP traffic; and 2.10 will extend coverage to include server-first protocols, as well as multicluster routing. The server-first mTLS should merge before the new year. We'll update this issue with llinks to our plans for authorization as they are documented. I'd expect this to move forward in January.

[glenjamin]

Awesome news - thank you for the update!

[christianhuening]

wow! great stuff!

[erwbgy]

@olix0r Is the plan to implement SMI Traffic Access Control, support calling an external authz provider (#2901) or something else?

As @cypherfox, @kubaj and others have noted, some of us already have an external authz provider that implements the Envoy External Authorization API (like opa-envoy-plugin) so it would be great if Linkerd could be configured to use it like we can with our ingress controllers.

[bklaubos]

Ability for OPA to integrate with something like Okta would be most useful to allow Okta to be the central control plane
Assumption is that OPA will cache the authorization with some TTL to avoid rate-limiting issue with external authz providers
An OPA wrapper that provides this would be nice.

[olix0r]

I'm happy to share our initial proposal/prototype for policy in Linkerd: https://github.com/linkerd/polixy/blob/main/DESIGN.md. I'd like to keep discussions about this proposal in the discussions for that repo.

TLDR:

• Two new CRDs: Server and ServerAuthorization;
  • OPA/GateKeeper/etc may be used to control what types of authorizations may be created.
• Purely connection-oriented for now -- HTTP verbs/URIs/headers are not part of this initial specification. We expect this support to follow.
• We plan to provide an SMI-compatible adapter as a Linkerd extension.

These choices have been made so that we can:

• Minimize runtime complexity/overhead.
• Provide a simple solution that can be adopted incrementally.
• Embraces Kubernetes primitives;
• Establishing building blocks that we can reuse for other (non-Authorization) types of server-side configuration.

And, this plan doesn't preclude other solutions in the future.

We're eager for questions and feedback!

[olix0r]

Linkerd stable-2.11.0 includes support for server authorization policies.