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

Have the Webhook react to pod creation/update only #2472

Merged
merged 7 commits into from
Mar 26, 2019
Merged

Conversation

alpeb
Copy link
Member

@alpeb alpeb commented Mar 7, 2019

This was already working almost out-of-the-box, just had to:

  • Change the webhook config so it watches pods instead of deployments
  • Grant some extra ClusterRole permissions
  • Add the piece that figures what's the OwnerReference and add the label
    for it

Tested fine when applying new yamls for Deployments and StatefulSets.

Fixes #2342 and #1751

@alpeb alpeb changed the title Have the Webhook react to pod creation/update only WIP: Have the Webhook react to pod creation/update only Mar 7, 2019
@alpeb alpeb changed the title WIP: Have the Webhook react to pod creation/update only Have the Webhook react to pod creation/update only Mar 11, 2019
@alpeb
Copy link
Member Author

alpeb commented Mar 11, 2019

This is ready for review now.
One caveat: we're not copying the pod labels into its parent workload (deployment, job, daemonset or statefulset). When using the CLI, that is done automatically by Kubernetes when creating the workload with kubectl apply. And we were doing that manually in the webhook when we were listening to Deployments.
Doing that now that we're only dealing with pod creation/update events would require hitting the Kubernetes API to update those labels, and additional permissions for the proxy-injector ClusterRole.
But if I'm not mistaking those labels aren't really useful. If I'm mistaking, let me know 😉

@alpeb alpeb marked this pull request as ready for review March 11, 2019 21:44
@siggy siggy added the priority/P0 Release Blocker label Mar 11, 2019
Copy link
Member

@siggy siggy left a comment

Choose a reason for hiding this comment

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

not sure if this is my environment, but getting startup failures following auto-injection:

$ kubectl -n emojivoto logs -f pod/vote-bot-644ddf8596-n44tz linkerd-proxy
ERR! linkerd2_proxy::transport::tls::identity Invalid DNS name: [46, 112, 111, 100, 46, 101, 109, 111, 106, 105, 118, 111, 116, 111, 46, 108, 105, 110, 107, 101, 114, 100, 45, 109, 97, 110, 97, 103, 101, 100, 46, 108, 105, 110, 107, 101, 114, 100, 46, 115, 118, 99, 46, 99, 108, 117, 115, 116, 101, 114, 46, 108, 111, 99, 97, 108]
configuration error: InvalidEnvVar

steps to reproduce

bin/linkerd install --proxy-auto-inject --tls optional | kubectl apply -f -

use this gist:

curl https://gist.githubusercontent.com/siggy/867ae15d7e1c48c0d6cb2fb4f92f24d5/raw/5c4f5738e56b19f14dc42faa3773c1da72fae6d5/emojivoto-auto-inject.yml | kubectl apply -f -

Diffing the output of kubectl -n emojivoto get all -oyaml against master reveals a few notable differences:

this branch

      volumeMounts:
      - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
        name: emoji-token-pjdtg
        readOnly: true
...
      - name: LINKERD2_PROXY_ID
        value: .pod.$LINKERD2_PROXY_POD_NAMESPACE.linkerd-managed.linkerd.svc.cluster.local

master

      volumeMounts:
      - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
        name: default-token-rz8qb
        readOnly: true
...
      - name: LINKERD2_PROXY_ID
        value: emoji.deployment.$LINKERD2_PROXY_POD_NAMESPACE.linkerd-managed.linkerd.svc.cluster.local
...
      # this block only present on master
      - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
        name: default-token-rz8qb
        readOnly: true
...
      # this block only present on master
      volumeMounts:
      - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
        name: default-token-rz8qb
        readOnly: true

@olix0r
Copy link
Member

olix0r commented Mar 11, 2019

If this is particularly difficult to fix, I should note that the identity/master branch changes the ID structure such that no parent information need be reference by the injector.

@alpeb
Copy link
Member Author

alpeb commented Mar 12, 2019

Thanks for the detailed check @siggy! (I'll have to get into the habit of testing things with TLS enabled...)

I tried fixing the LINKERD2_PROXY_ID value by setting it to the pod's "generated name", which would end up something like vote-bot-c78795449-.pod.$LINKERD2_PROXY_POD_NAMESPACE.linkerd-managed.linkerd.svc.cluster.local, but that still doesn't fix the proxy error. Having it refer to the parent deployment would require changes that will need to be discarded afterwards per @olix0r's comment above, so I'm leaving it as is for now.

As for the missing serviceaccount mount paths, I believe the cause is as follows:

TL;DR: The injected sidecar + initContainer don't pass through the Service Account admission controller, so we have to manually add the missing mount paths.

The Service Account admission controller is the one in charge of automatically adding those mounts when a pod enters the system, and that's always run before our mutating admission webhook.

When we were dealing with Deployments, we injected our sidecar and initContainer into the Deployment spec, then that created a Pod which went through the Service Account admission controller and got its mount paths set.

Now that we listen to Pod creation only, the Pod we receive in the webhook has already gone through the Service Account admission controller, which is confirmed by the mount path being correctly set in the uninjected container. We then proceed to inject our containers, but the Pod won't go again through the Service Account admission controller, so the mount path for our new containers won't get set.

As a solution I will be manually adding those mount paths.

Copy link
Member

@siggy siggy left a comment

Choose a reason for hiding this comment

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

Hmm, I'm still seeing:

$ kubectl -n emojivoto logs -f pod/emoji-7cdf7ff5d-9d94q linkerd-proxy
ERR! linkerd2_proxy::transport::tls::identity Invalid DNS name: [101, 109, 111, 106, 105, 45, 55, 99, 100, 102, 55, 102, 102, 53, 100, 45, 46, 112, 111, 100, 46, 101, 109, 111, 106, 105, 118, 111, 116, 111, 46, 108, 105, 110, 107, 101, 114, 100, 45, 109, 97, 110, 97, 103, 101, 100, 46, 108, 105, 110, 107, 101, 114, 100, 46, 115, 118, 99, 46, 99, 108, 117, 115, 116, 101, 114, 46, 108, 111, 99, 97, 108]
configuration error: InvalidEnvVar

Decoding those bytes yields:

emoji-7cdf7ff5d-.pod.emojivoto.linkerd-managed.linkerd.svc.cluster.local

...maybe the trailing hyphen is a problem?

      - name: LINKERD2_PROXY_ID
        value: emoji-7cdf7ff5d-.pod.$LINKERD2_PROXY_POD_NAMESPACE.linkerd-managed.linkerd.svc.cluster.local

@alpeb
Copy link
Member Author

alpeb commented Mar 12, 2019

Following up on our conversation, I've disabled --tls optional to avoid hitting these errors. This means this branch will depend on the Identity branch to get merged first.

@alpeb
Copy link
Member Author

alpeb commented Mar 19, 2019

I've just rebased now that the --tls flag in master has been dropped, so this branch can be reviewed without any disclaimers. The plan is to merge this before #2500, as it simplifies the webhook logic.

Copy link
Contributor

@klingerf klingerf left a comment

Choose a reason for hiding this comment

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

Nice, glad to see that this is straightforward to setup. I've suggested a different approach below for finding pod owners, so that we don't have to implement owner reference parsing twice in the codebase, but let me know if my comments don't make sense.

controller/proxy-injector/webhook.go Outdated Show resolved Hide resolved
chart/templates/proxy_injector.yaml Outdated Show resolved Hide resolved
pkg/k8s/labels.go Show resolved Hide resolved
Copy link
Contributor

@ihcsim ihcsim left a comment

Choose a reason for hiding this comment

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

LGTM. Just one question.

controller/proxy-injector/webhook.go Outdated Show resolved Hide resolved
@ihcsim
Copy link
Contributor

ihcsim commented Mar 20, 2019

One TIOLI: I notice there is still a patch = NewPatchDeployment() in GetPatch(). We definitely still need it to support CLI inject of different kinds of workloads. I wonder if we can make it more generic, since those patches work for other non-workload types. (For a second, I thought that only works for Deployment and we somehow broke CLI inject 😆).

One suggestion is to just replace the two constructors with a more general NewPatch() constructor, and use a kind parameter to decide which paths to use.

@alpeb
Copy link
Member Author

alpeb commented Mar 20, 2019

@ihcsim yeah, NewPatchDeployment is not a generic-enough name hehe. I'll implement your suggestion based on 'Kind` 👍

@ihcsim
Copy link
Contributor

ihcsim commented Mar 20, 2019

In addition to the issue with auto-injecting single pod without labels, there is another minor one. The log msg is missing the workload name:

proxy-injector time="2019-03-20T22:38:55Z" level=info msg="patch generated for: Pod"

I think the ResourceConfig.String() method needs to look for the workload name in podSpec, instead of workLoad.

@alpeb
Copy link
Member Author

alpeb commented Mar 21, 2019

I think the ResourceConfig.String() method needs to look for the workload name in podSpec, instead of workLoad.

Actually podSpec doesn't hold the pod's name either, so we have to rely on the admission request data. I'll fix that.

@alpeb
Copy link
Member Author

alpeb commented Mar 22, 2019

Thank you guys for all your feedback. Here's a new push with everything addressed.

@klingerf I'm now using GetOwnerKindAndName() as you suggested, although I finally didn't get to change its signature because it implied lots of changes elsewhere so it wasn't worth it.

@ihcsim Given the payload received by the webhook is a little different in regards to metadata, I had to get rid of the ResourceConfig.String() method, and I'm letting the report produce that string (I also dropped the namespace from there for simplicity).

Sorry I had to rebase one more time, to keep in sync with the Identity changes.

This was already working almost out-of-the-box, just had to:

- Change the webhook config so it watches pods instead of deployments
- Grant some extra ClusterRole permissions
- Add the piece that figures what's the OwnerReference and add the label
for it

Fixes #2342 and #1751

Signed-off-by: Alejandro Pedraza <[email protected]>
Signed-off-by: Alejandro Pedraza <[email protected]>
Signed-off-by: Alejandro Pedraza <[email protected]>
Signed-off-by: Alejandro Pedraza <[email protected]>
Copy link
Contributor

@ihcsim ihcsim left a comment

Choose a reason for hiding this comment

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

Thanks for rebasing with master. Some comments below.

controller/proxy-injector/webhook.go Outdated Show resolved Hide resolved
controller/proxy-injector/webhook_test.go Outdated Show resolved Hide resolved
pkg/inject/inject.go Outdated Show resolved Hide resolved
@@ -362,10 +355,20 @@ func (conf *ResourceConfig) complete(template *v1.PodTemplateSpec) {
conf.pod.Meta = &template.ObjectMeta
}

// GetPod returns the parsed object as a *v1.Pod variable
func (conf *ResourceConfig) GetPod() (*v1.Pod, error) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Probably not needed if you moved the logic of webhook.getLabelForParent() into this package.

Copy link
Member Author

Choose a reason for hiding this comment

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

inject.go is not dependent on k8s.API, which is needed in getLabelForParent(). That's why I kept the pod object retrieval logic separated from the logic that retrieves its ownership, which is only used in the webhook.

@@ -27,21 +27,25 @@ func newReport(conf *ResourceConfig) Report {
var name string
if m := conf.pod.Meta; m != nil {
name = m.Name
if name == "" {
name = m.GenerateName
Copy link
Contributor

Choose a reason for hiding this comment

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

Not sure how useful this will be, as it only returns the prefix of the pod name like linkerd-controller-7c6b8c586b-. Will there be cases where the pod name will be empty? The parent workload name, if non-empty, might be more useful.

Copy link
Member Author

Choose a reason for hiding this comment

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

The pod name appears to be always empty in the admission request metadata, and we only have access to that GenerateName, which is actually the ReplicaSet's name (plus a dash). I think this is a bit more informative (linkerd-controller-7c6b8c586b-) than the Deployment's name (linkerd-controller).

Copy link
Contributor

@klingerf klingerf left a comment

Choose a reason for hiding this comment

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

Great, thanks for switching to k8s.API. Approach looks good to me, but I was a bit confused by the handling of the namespace in the pod meta -- see my comments below. Also had just a few other random bits of feedback.

chart/templates/proxy_injector.yaml Show resolved Hide resolved
controller/proxy-injector/webhook.go Outdated Show resolved Hide resolved
controller/proxy-injector/webhook_test.go Outdated Show resolved Hide resolved
pkg/inject/inject.go Outdated Show resolved Hide resolved
pkg/inject/inject.go Outdated Show resolved Hide resolved
pkg/inject/report.go Show resolved Hide resolved
Copy link
Member

@siggy siggy left a comment

Choose a reason for hiding this comment

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

This all works on my machine. Had mostly questions...

controller/proxy-injector/webhook.go Outdated Show resolved Hide resolved
controller/proxy-injector/webhook.go Outdated Show resolved Hide resolved
pkg/inject/inject.go Outdated Show resolved Hide resolved
Signed-off-by: Alejandro Pedraza <[email protected]>
return pkgK8s.ProxyStatefulSetLabel, name, nil
}
return "", "", fmt.Errorf("unsupported parent kind \"%s\"", kind)
func (w *Webhook) ownerRetriever(ns string) inject.OwnerRetrieverFunc {
Copy link
Member Author

Choose a reason for hiding this comment

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

who said go cannot haz curry? 🐱

@@ -154,158 +153,6 @@ func TestGetPatch(t *testing.T) {
})
}

func TestGetLabelForParent(t *testing.T) {
Copy link
Member Author

Choose a reason for hiding this comment

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

Given we no longer have GetLabelForParent() I removed this test, but created #2560 to complete the webhook tests, that we can address in the 2.3 testing sprint.

Copy link
Contributor

@klingerf klingerf left a comment

Choose a reason for hiding this comment

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

⭐️ Looks great! Thanks for making those updates.

cli/cmd/inject.go Outdated Show resolved Hide resolved
pkg/inject/inject.go Show resolved Hide resolved
pkg/inject/patch_test.go Show resolved Hide resolved
Copy link
Member

@siggy siggy left a comment

Choose a reason for hiding this comment

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

thanks for the updates! 👍 🚢

pkg/inject/inject.go Outdated Show resolved Hide resolved
Signed-off-by: Alejandro Pedraza <[email protected]>
@l5d-bot
Copy link
Collaborator

l5d-bot commented Mar 26, 2019

Integration test results for 122bdb2: success 🎉
Log output: https://gist.github.com/d8684f23238f0c8e0818e4fdc30b63ec

@alpeb alpeb merged commit 7efe385 into master Mar 26, 2019
@alpeb alpeb deleted the alpeb/webhook-pods branch March 26, 2019 16:54
hawkw added a commit that referenced this pull request Sep 25, 2023
This branch cherry-picks #2472 onto `release/v2.203`.

Currently, the proxy [depends on an outdated version of `rustls`][1],
v0.20.8. The `rustls` dependency is via our dependency on `tokio-rustls`
v0.23.4; we don't have a direct `rustls` dependency, in order to ensure
that the version of `rustls` is always the same version as used by
`tokio-rustls`. `rustls` also has a dependency on `webpki`, and v0.20.x
of `rustls` uses the original `webpki` crate, rather than the
`rustls-webpki` crate. So, unfortunately, because we have a transitive
dep on `webpki` via `rustls`, PR linkerd/linkerd2-proxy#2465 did not
remove _all_ `webpki` deps from our dependency tree, only the direct
dependency.

This branch updates to `rustls` v0.21.x, which depends on
`rustls-webpki` rather than `webpki`, removing the `webpki` dependency.
This is accomplished by updating `tokio-rustls` to v0.24.x, implicitly
updating the transitive `rustls` dep. In order to update to the
semver-incompatible version of `rustls`, it was necessary to modify our
code in order to track some breaking API changes. I've also added a
`cargo-deny` ban for `webpki` to our `deny.toml`, to ensure that we
always use the actively-maintained `rustls-webpki` crate rather than
`webpki` classic.

Since peer certificate validation is performed through `rustls` rather
than through the direct `rustls-webpki` dependency, this should
hopefully resolve issues with issuer certs that contain name constraints
--- these were not fixed by linkerd/linkerd2-proxy#2465, because the
failure with certs containing name constraints occurred inside of the
*`webpki` version depended on by `rustls`*, rather than inside of the
proxy's direct dep. See [this comment][2] for details.

In addition, it was necessary to update `rustls-webpki` to v0.101.6,
since v0.101.5 was yanked due to an accidental API breaking change.

<details>

<summary>Verifying that we no longer depend on `webpki`:</summary>

Before:

```console
$ cargo tree -p webpki -i
webpki v0.22.1
├── rustls v0.20.8
│   └── tokio-rustls v0.23.4
│       ├── linkerd-app-integration v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/integration)
│       └── linkerd-meshtls-rustls v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/meshtls/rustls)
│           ├── linkerd-app-inbound v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/inbound)
│           │   ├── linkerd-app v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app)
│           │   │   ├── linkerd-app-integration v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/integration)
│           │   │   └── linkerd2-proxy v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd2-proxy)
│           │   ├── linkerd-app-admin v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/admin)
│           │   │   └── linkerd-app v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app) (*)
│           │   │   [dev-dependencies]
│           │   │   └── linkerd-app-integration v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/integration)
│           │   └── linkerd-app-gateway v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/gateway)
│           │       └── linkerd-app v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app) (*)
│           │   [dev-dependencies]
│           │   └── linkerd-app-gateway v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/gateway) (*)
│           ├── linkerd-app-outbound v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/outbound)
│           │   ├── linkerd-app v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app) (*)
│           │   └── linkerd-app-gateway v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/gateway) (*)
│           │   [dev-dependencies]
│           │   └── linkerd-app-gateway v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/gateway) (*)
│           └── linkerd-meshtls v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/meshtls)
│               ├── linkerd-app-core v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/core)
│               │   ├── linkerd-app v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app) (*)
│               │   ├── linkerd-app-admin v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/admin) (*)
│               │   ├── linkerd-app-gateway v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/gateway) (*)
│               │   ├── linkerd-app-inbound v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/inbound) (*)
│               │   ├── linkerd-app-integration v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/integration)
│               │   ├── linkerd-app-outbound v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/outbound) (*)
│               │   └── linkerd-app-test v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/test)
│               │       ├── linkerd-app-inbound v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/inbound) (*)
│               │       ├── linkerd-app-integration v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/integration)
│               │       └── linkerd-app-outbound v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/outbound) (*)
│               │       [dev-dependencies]
│               │       ├── linkerd-app-gateway v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/gateway) (*)
│               │       ├── linkerd-app-inbound v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/inbound) (*)
│               │       └── linkerd-app-outbound v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/outbound) (*)
│               ├── linkerd-app-inbound v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/inbound) (*)
│               ├── linkerd-proxy-tap v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/proxy/tap)
│               │   └── linkerd-app-core v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/core) (*)
│               └── linkerd2-proxy v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd2-proxy)
│               [dev-dependencies]
│               ├── linkerd-app-inbound v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/inbound) (*)
│               ├── linkerd-app-integration v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/integration)
│               └── linkerd-app-outbound v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/outbound) (*)
│           [dev-dependencies]
│           ├── linkerd-app-inbound v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/inbound) (*)
│           └── linkerd-app-outbound v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/outbound) (*)
└── tokio-rustls v0.23.4 (*)
```

After:

```console
$ cargo tree -p webpki -i
error: package ID specification `webpki` did not match any packages
```

</details>

[1]:
    https://github.com/linkerd/linkerd2-proxy/blob/8afc72258b8ced868fbd0bde0235955c0adf4ccd/Cargo.lock#L2450-L2460C2
[2]:
    #9299 (comment)

---

0e843c9f meshtls: update to `rustls` v0.21.7 (linkerd/linkerd2-proxy#2473)

Signed-off-by: Eliza Weisman <[email protected]>
@hawkw hawkw mentioned this pull request Sep 25, 2023
mateiidavid pushed a commit that referenced this pull request Sep 25, 2023
This branch cherry-picks #2472 onto `release/v2.203`.

Currently, the proxy [depends on an outdated version of `rustls`][1],
v0.20.8. The `rustls` dependency is via our dependency on `tokio-rustls`
v0.23.4; we don't have a direct `rustls` dependency, in order to ensure
that the version of `rustls` is always the same version as used by
`tokio-rustls`. `rustls` also has a dependency on `webpki`, and v0.20.x
of `rustls` uses the original `webpki` crate, rather than the
`rustls-webpki` crate. So, unfortunately, because we have a transitive
dep on `webpki` via `rustls`, PR linkerd/linkerd2-proxy#2465 did not
remove _all_ `webpki` deps from our dependency tree, only the direct
dependency.

This branch updates to `rustls` v0.21.x, which depends on
`rustls-webpki` rather than `webpki`, removing the `webpki` dependency.
This is accomplished by updating `tokio-rustls` to v0.24.x, implicitly
updating the transitive `rustls` dep. In order to update to the
semver-incompatible version of `rustls`, it was necessary to modify our
code in order to track some breaking API changes. I've also added a
`cargo-deny` ban for `webpki` to our `deny.toml`, to ensure that we
always use the actively-maintained `rustls-webpki` crate rather than
`webpki` classic.

Since peer certificate validation is performed through `rustls` rather
than through the direct `rustls-webpki` dependency, this should
hopefully resolve issues with issuer certs that contain name constraints
--- these were not fixed by linkerd/linkerd2-proxy#2465, because the
failure with certs containing name constraints occurred inside of the
*`webpki` version depended on by `rustls`*, rather than inside of the
proxy's direct dep. See [this comment][2] for details.

In addition, it was necessary to update `rustls-webpki` to v0.101.6,
since v0.101.5 was yanked due to an accidental API breaking change.

[1]:
    https://github.com/linkerd/linkerd2-proxy/blob/8afc72258b8ced868fbd0bde0235955c0adf4ccd/Cargo.lock#L2450-L2460C2
[2]:
    #9299 (comment)

---

0e843c9f meshtls: update to `rustls` v0.21.7 (linkerd/linkerd2-proxy#2473)

Signed-off-by: Eliza Weisman <[email protected]>
mateiidavid pushed a commit that referenced this pull request Sep 25, 2023
This branch cherry-picks #2472 onto `release/v2.203`.

Currently, the proxy [depends on an outdated version of `rustls`][1],
v0.20.8. The `rustls` dependency is via our dependency on `tokio-rustls`
v0.23.4; we don't have a direct `rustls` dependency, in order to ensure
that the version of `rustls` is always the same version as used by
`tokio-rustls`. `rustls` also has a dependency on `webpki`, and v0.20.x
of `rustls` uses the original `webpki` crate, rather than the
`rustls-webpki` crate. So, unfortunately, because we have a transitive
dep on `webpki` via `rustls`, PR linkerd/linkerd2-proxy#2465 did not
remove _all_ `webpki` deps from our dependency tree, only the direct
dependency.

This branch updates to `rustls` v0.21.x, which depends on
`rustls-webpki` rather than `webpki`, removing the `webpki` dependency.
This is accomplished by updating `tokio-rustls` to v0.24.x, implicitly
updating the transitive `rustls` dep. In order to update to the
semver-incompatible version of `rustls`, it was necessary to modify our
code in order to track some breaking API changes. I've also added a
`cargo-deny` ban for `webpki` to our `deny.toml`, to ensure that we
always use the actively-maintained `rustls-webpki` crate rather than
`webpki` classic.

Since peer certificate validation is performed through `rustls` rather
than through the direct `rustls-webpki` dependency, this should
hopefully resolve issues with issuer certs that contain name constraints
--- these were not fixed by linkerd/linkerd2-proxy#2465, because the
failure with certs containing name constraints occurred inside of the
*`webpki` version depended on by `rustls`*, rather than inside of the
proxy's direct dep. See [this comment][2] for details.

In addition, it was necessary to update `rustls-webpki` to v0.101.6,
since v0.101.5 was yanked due to an accidental API breaking change.

[1]:
    https://github.com/linkerd/linkerd2-proxy/blob/8afc72258b8ced868fbd0bde0235955c0adf4ccd/Cargo.lock#L2450-L2460C2
[2]:
    #9299 (comment)

---

0e843c9f meshtls: update to `rustls` v0.21.7 (linkerd/linkerd2-proxy#2473)

Signed-off-by: Eliza Weisman <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority/P0 Release Blocker
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants