Skip to content

outbound: discover client policies from the OutboundPolicy API#2265

Merged
olix0r merged 86 commits intomainfrom
eliza/policy-discovery
Mar 11, 2023
Merged

outbound: discover client policies from the OutboundPolicy API#2265
olix0r merged 86 commits intomainfrom
eliza/policy-discovery

Conversation

@hawkw
Copy link
Contributor

@hawkw hawkw commented Feb 24, 2023

This branch changes the outbound proxy to resolve client policies using
the OutboundPolicy proxy-api service (added in
linkerd/linkerd2-proxy-api#165). The proxy will preferentially use an
OutboundPolicy resolution over a ServiceProfile resolution in the
case that both are resolved and the OutboundPolicy is not a default
policy. If the OutboundPolicy is a default policy, it is used only
when no ServiceProfile is resolved. The ingress-mode proxy also
performs OutboundPolicy resolutions.

This branch also adds an implementation of the OutboundPolicy service
to the mock policy controller in linkerd-app-integration, and some
integration tests for client policies (including header-based routing).

Some notes:

  • The policy controller address, policy controller name, and workload
    identifier environment variables are now mandatory, since the proxy
    will always attempt to resolve outbound client policies.
  • Currently, targets constructed from an OutboundPolicy will report
    the original destination address as their LogicalAddr, rather than
    an authority. In the future, we will change the way metrics, tap, and
    error labels work to obviate the need for LogicalAddrs, and use
    structured metadata here instead.
  • We probably ought to add additional tests in follow-up branches.
  • I don't love that the TargetAddr type, which is the target
    address for both ServiceProfile and OutboundPolicy resolutions,
    has to live in the linkerd-client-policy crate. But unfortunately,
    it cannot be defined in linkerd-app-outbound, as the direct stack in
    linkerd-app-inbound must also implement Param<TargetAddr>.
  • The gateway doesn't currently resolve client policies, but I'll have a
    follow-up PR for that ready shortly.

hawkw added 11 commits February 24, 2023 12:01
And, pull the discovery allowlist out into a wrapper around
`GetProfile`. This way, a discovery service performing profile
discovery, policy discovery, or both can be passed into `push_discover`,
depending on the stack.
This reverts commit 04f4dcf.
@hawkw hawkw force-pushed the eliza/policy-discovery branch from 6602162 to 0e1cbc8 Compare February 24, 2023 20:01
; Conflicts:
;	linkerd/app/inbound/src/policy/config.rs
;	linkerd/app/inbound/src/policy/store.rs
;	linkerd/app/inbound/src/server.rs
;	linkerd/app/inbound/src/test_util.rs
;	linkerd/app/src/env.rs
@hawkw
Copy link
Contributor Author

hawkw commented Feb 27, 2023

pushed test docker image mycoliza/l2-proxy:eliza.policy-discovery.744bd98c7

olix0r
olix0r previously approved these changes Mar 11, 2023
* Split out synthetic policies for readability

* wi

* fix discovery integration tests

* fixup integration

* golf

* clarity

* Differentiate forward metadata

* Update linkerd/app/outbound/src/discover.rs

---------

Co-authored-by: Eliza Weisman <eliza@buoyant.io>
let profiles = support::profile::resolver().profile(addr, profiles::Profile::default());
svc::mk(move |OrigDstAddr(addr)| {
// TODO(eliza): policy!
profiles.clone().oneshot(profiles::LookupAddr(addr.into()))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does this test care about profiles or policies at all, really? What are we testing?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i don't think this test actually cares besides that it needs something it can construct an inner stack from. if we remove theFrom<(Option<profile::Receiver>, T)> impl for Discovery<T> (making both a policy rx mandatory), we will need to return both a policy and profile rx here as well.

i believe this test is testing the behavior of the push_discover stack, so we can't just remove that entirely.

@olix0r olix0r dismissed their stale review March 11, 2023 18:21

outdated

Co-authored-by: Oliver Gould <ver@buoyant.io>
hawkw and others added 2 commits March 11, 2023 10:55
Make clearer assertions about supported routing states.
@olix0r olix0r merged commit 3dec105 into main Mar 11, 2023
@olix0r olix0r deleted the eliza/policy-discovery branch March 11, 2023 22:41
olix0r added a commit to linkerd/linkerd2 that referenced this pull request Mar 11, 2023
To support Gateway API-style routes in the outbound proxy, we need to begin
discovering this route configuration from the control plane (via the new
`OutboundPolicies` API).

This change updates the proxy as follows:

1. Policy controller configuration is now required for the proxy.
   Previously, the policy API was optionally configured for the inbound
   proxy.
2. The sidecar and ingress proxies are updated to use client policies.
   Service profile configurations continue to be used when they include
   HTTP routes and/or traffic split. Otherwise, a client policy is used
   to route traffic.

Outbound policies are currently discovered for *all* outbound IP addresses. Over
time, the policy controller will assume responsibility to make *all* routing
decisions.  It does not yet serve responses for all cases, however, so some
fallback behavior exists to use endpoint metadata from profile discovery,
if it exists.

The multi-cluster gateway configuration does not yet use policies for
outbound routing. Furthermore, the proxy reports an IP logical address for
policy routes (instead of a named address, as is done with profiles). There
are no new metrics or labels introduced in this PR. Metrics changes will be made
in follow-up changes.

---

* outbound: Decouple backend caching from request distribution (linkerd/linkerd2-proxy#2284)
* build(deps): bump socket2 from 0.4.7 to 0.4.9 (linkerd/linkerd2-proxy#2290)
* README: comment just-cargo and make it more clear (linkerd/linkerd2-proxy#2292)
* build(deps): bump prettyplease from 0.1.23 to 0.1.24 (linkerd/linkerd2-proxy#2293)
* build(deps): bump tokio from 1.25.0 to 1.26.0 (linkerd/linkerd2-proxy#2286)
* build(deps): bump petgraph from 0.6.2 to 0.6.3 (linkerd/linkerd2-proxy#2285)
* client-policy: add protobuf conversion (linkerd/linkerd2-proxy#2289)
* integration: add test policy controller (linkerd/linkerd2-proxy#2288)
* outbound: change `push_discover` to take a `Service` (linkerd/linkerd2-proxy#2291)
* build(deps): bump rustix from 0.36.7 to 0.36.9 (linkerd/linkerd2-proxy#2295)
* build(deps): bump serde_json from 1.0.93 to 1.0.94 (linkerd/linkerd2-proxy#2296)
* build(deps): bump async-trait from 0.1.64 to 0.1.66 (linkerd/linkerd2-proxy#2297)
* build(deps): bump thiserror from 1.0.38 to 1.0.39 (linkerd/linkerd2-proxy#2298)
* build(deps): bump mio from 0.8.5 to 0.8.6 (linkerd/linkerd2-proxy#2299)
* separate policy client config from `inbound::Config` (linkerd/linkerd2-proxy#2307)
* outbound: Require ClientPolicy discovery (linkerd/linkerd2-proxy#2265)

Signed-off-by: Oliver Gould <ver@buoyant.io>
olix0r added a commit to linkerd/linkerd2 that referenced this pull request Mar 13, 2023
To support Gateway API-style routes in the outbound proxy, we need to begin
discovering this route configuration from the control plane (via the new
`OutboundPolicies` API).

This change updates the proxy as follows:

1. Policy controller configuration is now required for the proxy.
   Previously, the policy API was optionally configured for the inbound
   proxy.
2. The sidecar and ingress proxies are updated to use client policies.
   Service profile configurations continue to be used when they include
   HTTP routes and/or traffic split. Otherwise, a client policy is used
   to route traffic.

Outbound policies are currently discovered for *all* outbound IP addresses. Over
time, the policy controller will assume responsibility to make *all* routing
decisions.  It does not yet serve responses for all cases, however, so some
fallback behavior exists to use endpoint metadata from profile discovery,
if it exists.

The multi-cluster gateway configuration does not yet use policies for
outbound routing. Furthermore, the proxy reports an IP logical address for
policy routes (instead of a named address, as is done with profiles). There
are no new metrics or labels introduced in this PR. Metrics changes will be made
in follow-up changes.

---

* outbound: Decouple backend caching from request distribution (linkerd/linkerd2-proxy#2284)
* build(deps): bump socket2 from 0.4.7 to 0.4.9 (linkerd/linkerd2-proxy#2290)
* README: comment just-cargo and make it more clear (linkerd/linkerd2-proxy#2292)
* build(deps): bump prettyplease from 0.1.23 to 0.1.24 (linkerd/linkerd2-proxy#2293)
* build(deps): bump tokio from 1.25.0 to 1.26.0 (linkerd/linkerd2-proxy#2286)
* build(deps): bump petgraph from 0.6.2 to 0.6.3 (linkerd/linkerd2-proxy#2285)
* client-policy: add protobuf conversion (linkerd/linkerd2-proxy#2289)
* integration: add test policy controller (linkerd/linkerd2-proxy#2288)
* outbound: change `push_discover` to take a `Service` (linkerd/linkerd2-proxy#2291)
* build(deps): bump rustix from 0.36.7 to 0.36.9 (linkerd/linkerd2-proxy#2295)
* build(deps): bump serde_json from 1.0.93 to 1.0.94 (linkerd/linkerd2-proxy#2296)
* build(deps): bump async-trait from 0.1.64 to 0.1.66 (linkerd/linkerd2-proxy#2297)
* build(deps): bump thiserror from 1.0.38 to 1.0.39 (linkerd/linkerd2-proxy#2298)
* build(deps): bump mio from 0.8.5 to 0.8.6 (linkerd/linkerd2-proxy#2299)
* separate policy client config from `inbound::Config` (linkerd/linkerd2-proxy#2307)
* outbound: Require ClientPolicy discovery (linkerd/linkerd2-proxy#2265)
* just: Fix docker tag formatting (linkerd/linkerd2-proxy#2312)
* outbound: Report concrete authorities for policies (linkerd/linkerd2-proxy#2313)

Signed-off-by: Oliver Gould <ver@buoyant.io>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants