Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

provide Service-to-Service authorization #3342

Closed
cypherfox opened this issue Aug 29, 2019 · 16 comments
Closed

provide Service-to-Service authorization #3342

cypherfox opened this issue Aug 29, 2019 · 16 comments

Comments

@cypherfox
Copy link
Contributor

cypherfox commented Aug 29, 2019

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
Copy link
Contributor Author

cypherfox commented Aug 30, 2019

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
Copy link

kubaj commented Oct 22, 2019

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
Copy link

stale bot commented Jan 20, 2020

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 stale bot added the wontfix label Jan 20, 2020
@stale
Copy link

stale bot commented Apr 19, 2020

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 stale bot added the wontfix label Apr 19, 2020
@cypherfox
Copy link
Contributor Author

cypherfox commented Jun 17, 2020

@stale
Copy link

stale bot commented Sep 19, 2020

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 stale bot added the wontfix label Sep 19, 2020
@stale stale bot closed this as completed Oct 4, 2020
@jgarces21
Copy link
Contributor

jgarces21 commented Oct 19, 2020

I think this one is related to #2746

@cypherfox
Copy link
Contributor Author

cypherfox commented Oct 19, 2020

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
Copy link

glenjamin commented Dec 11, 2020

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 olix0r reopened this Dec 22, 2020
@stale stale bot removed the wontfix label Dec 22, 2020
@olix0r olix0r added the pinned label Dec 22, 2020
@olix0r olix0r self-assigned this Dec 22, 2020
@olix0r
Copy link
Member

olix0r commented Dec 22, 2020

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
Copy link

glenjamin commented Dec 22, 2020

Awesome news - thank you for the update!

@christianhuening
Copy link
Contributor

christianhuening commented Dec 23, 2020

wow! great stuff!

@erwbgy
Copy link

erwbgy commented Jan 2, 2021

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

@olix0r olix0r added this to the stable-2.11 milestone Jan 14, 2021
@bklaubos
Copy link

bklaubos commented Apr 28, 2021

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
Copy link
Member

olix0r commented May 7, 2021

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 pushed a commit to linkerd/linkerd2-proxy that referenced this issue May 12, 2021
Applications have no way to know whether a request was transported
via Linkerd's mTLS and, if it was, what the client's identity was.

This change sets the `l5d-client-id` header with the value of the client's
identity name. Furthermore, any prior values for this header are stripped
from inbound requests so that client identities may not be spoofed.

This header is set on all inbound requests over meshed connections. This
behavior may be made configurable in the future. 

Related to linkerd/linkerd2#3342 and linkerd/linkerd2#3756
@olix0r
Copy link
Member

olix0r commented Sep 30, 2021

Linkerd stable-2.11.0 includes support for server authorization policies.

@olix0r olix0r closed this as completed Sep 30, 2021
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Oct 31, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

9 participants