add product security team to approvals

[GregHanson]

Please provide a description for what this PR is for.

per TOC discussion on July 11, ensure product security members have approval permissions to security releases directory

And to help us figure out who should review this PR, please put an X in all the areas that this PR affects.

• [ ] Configuration Infrastructure
• [ ] Docs
• [ ] Installation
• [ ] Networking
• [ ] Performance and Scalability
• [ ] Policies and Telemetry
• [ ] Security
• [ ] Test and Release
• [ ] User Experience
• [ ] Developer Infrastructure

[istio-policy-bot]

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

• You can learn about how we write and maintain documentation, about our style guidelines, and about all 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 as 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, we sanitize the markdown, we ensure all hyperlinks point to valid location, and more. If your PR doesn't pass one of these checks, you'll see a red X in the status section of the page. Click on the Details link to get a list of the problems with your PR. Fix those problems and push an update to your PR. This will automatically rerun the tests and 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).

Thanks for contributing!

Courtesy of your friendly welcome wagon.

[ericvn]

Greg, as noted in today's TOC call, I'm not sure this is enough. Do you have a better idea on a sample PR that you would've liked to merge? https://github.com/istio/istio.io/pull/11392 is the last on I think.

Looking at those files, we would also have to cover .spelling for the CVE's, content/en/docs/releases/supported-releases/index.md for the table, expand to connect/en/news to cover release notes, and data/args.yml if it affects a patch on the latest release.

[GregHanson]

@jacob-delgado was there any particular release where you remember this being an issue? Just looking for a reference PR or we can follow Eric's recommendation based on last security release

[ericvn]

I don't actually recall this being to much of an issue, except maybe the last set (PR noted above) when I was out of country on vacation. Normally, I can cover the document approvals for you. I did think we had identified someone to cover for the last release before I left.

[craigbox]

Could we solve this by making someone on the PSWG a Docs maintainer? Or, is there any reason that security releases have a different coordination pattern than regular releases? Would we have the same problem there?

[ericvn]

The PSWG does have a communications role IIRC, but I think it did rotate some, so maybe a subset could be added as maintainers. I did notice at least one person on the PSWG list, maybe incorrectly, that also has a lot of authority and could certainly merge PRs if needed. Just another backup plan if a Doc person wasn't contacted beforehand or could't make it at the last minute.

I know that RMs also have releases (although typically not as important as a potential Day 0 release) and have to work with the Doc team

[jacob-delgado]

Getting docs approval can be difficult just due to the limited number of docs maintainers. Most of the time we've been able to get in contact with Eric, but that can be onerous on him to always be the POC for it on release day. Most of our activities during a release aren't relevant to docs, except for the merging of the PR into the latest release branch.

I'm also fine with us not having anyone on the list as long as there is a github admin we can get in contact with that can do a force merge. I just find it to be a bad practice to do that as we don't want to get into bad habits.

[istio-testing]

@GregHanson: PR needs rebase.

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/test-infra repository.

[istio-testing]

@GregHanson: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
doc.test.multicluster_istio.io	f5c4dca822e1a62867a07e895986e6f753b1f942	link	true	/test doc.test.multicluster
doc.test.profile_default_istio.io	f5c4dca822e1a62867a07e895986e6f753b1f942	link	true	/test doc.test.profile_default
doc.test.profile_demo_istio.io	f5c4dca822e1a62867a07e895986e6f753b1f942	link	true	/test doc.test.profile_demo
doc.test.profile_none_istio.io	f5c4dca822e1a62867a07e895986e6f753b1f942	link	true	/test doc.test.profile_none
doc.test.profile_minimal_istio.io	f5c4dca822e1a62867a07e895986e6f753b1f942	link	true	/test doc.test.profile_minimal
doc.test.profile-minimal_istio.io	f5c4dca822e1a62867a07e895986e6f753b1f942	link	true	/test doc.test.profile-minimal
doc.test.profile-demo_istio.io	f5c4dca822e1a62867a07e895986e6f753b1f942	link	true	/test doc.test.profile-demo
doc.test.profile-default_istio.io	f5c4dca822e1a62867a07e895986e6f753b1f942	link	true	/test doc.test.profile-default
doc.test.profile-none_istio.io	f5c4dca822e1a62867a07e895986e6f753b1f942	link	true	/test doc.test.profile-none

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/test-infra repository. I understand the commands that are listed here.

[GregHanson]

Looking at those files, we would also have to cover .spelling for the CVE's, content/en/docs/releases/supported-releases/index.md for the table, expand to connect/en/news to cover release notes, and data/args.yml if it affects a patch on the latest release.

closing this one for now. Adding all the necessary files would result in a lot more GitHub review requests unrelated to just security releases