Security Considerations on Istio's CRDs with Namespace-based Multi-Tenancy

[lorinl]

Description

This pull request addresses a security issue of a possible Man-in-the-Middle (MitM) attack scenario in which a VirtualService can redirect or intercept traffic within the service mesh. This affects Namespace-based Multi-Tenancy clusters where tenants have the permissions to deploy Istio resources (networking.istio.io/v1).

As discussed with @keithmattix and @dhawton through the security vulnerability report list, we address it by raising awareness on the topic through:

• a Security Bulletin which informs operators of Istio briefly about the issue, so they can decide if they need to take action in their deployments
• a blog post about Security Considerations on Istio's CRDs with Namespace-based Multi-Tenancy which goes into details about the risks involved with Namespace-based Multi-Tenancy in Istio
• an addition to the security model to point this out to readers of the documentation

Please note, we did not include the part "If a user wants to change the scope of where these resources are applied, they can use the exportTo field on each resource to control which namespaces the resource affects or deploy a Sidecar resource to control which namespaces a particular set of sidecars import configuration from." from our discussion as attackers wouldn't limit themselfes.

Reviewers

• Docs
• Security

CC: @SvenTo

[istio-policy-bot]

😊 Welcome! This is either your first contribution to the Istio documentation repo, or
it's been a while since you've been here. A few things you should know:

• You can learn about how we write and maintain documentation, our style guidelines,
  and the available web site features by visiting Contributing to the Docs.

• In the next few minutes, an automatic preview of your change will be built with
  a full copy of the istio.io website. You can find this preview by clicking on
  the Details link next to the deploy/netlify entry in the status section of this
  page.

• We care about quality, so we've put in place a number of checks to ensure our documentation
  is top-notch. We do spell checking, sanitize the Markdown, ensure all hyperlinks point to a
  valid location, and more. If your PR doesn't pass one of these checks, you'll see a red X in the
  lint_istio.io entry in the status section. Click on the Details link to get a list of the
  problems with your PR. Fix those problems and push an update; this will automatically re-run the
  tests. Hopefully this time everything will be perfect!

• Once your changes are accepted and merged into the repository, they will initially show up
  on https://preliminary.istio.io. The changes will be published to https://istio.io
  the next time we do a major release (which typically happens every 3 months or so).
  To publish them sooner, add a cherrypick/release-x.xx label, where x.xx is the current
  release of Istio.

Thanks for contributing!

Courtesy of your friendly welcome wagon.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: lorinl / name: lorinl (d949b4d)
• ✅ login: SvenTo / name: Sven Nobis (12c44b5, 1525486, 290be37, 30b5b19, 6eda291, 77949a7, ad4976f, b1fc712, c6e9ec5, f5d25e7, f7e6895)
• ✅ login: SvenTo / name: SvenTo (074d72c)

[istio-testing]

Hi @lorinl. Thanks for your PR.

I'm waiting for a istio member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[keithmattix]

/ok-to-test

[keithmattix]

Added some comments on specific technical details. From a tone perspective, it's important that we don't imply that these resources are inherently insecure. Rather, they are products of their time and have tradeoffs that users need to scrutinize when trying to use them in multi-tenant environments. As I describe in one of the comments, the key takeaway that those users should get from this article is that they should move to using Gateway API

[SvenTo]

Hi @keithmattix,
Thank you for the comments! We appreciate your valuable feedback and insights. We addressed your comments in the blog post and made the same changes to the security bulletin and security model.

In the mitigation section, we emphasize the migration to the Gateway API now.

Also, it should be clearer that the discussed problems affect only namespace-based multi-tenant environments, and it should emphasize to operators that they should address them. We don’t want to imply that the resources are inherently insecure in our post.