SECURITY_CONTACTS files

[Lubomir I. Ivanov]

hello,

as you may have seen Joel Smith from the Product Security Committee
has recently created a number of tickets in the kubernetes/kubernetes
repository to update SECURITY_CONTACTS files in our staged
repositories. this is due to the PSC delegating the per-repository
security contact to the repository owners.

e.g.
https://github.com/kubernetes/kubernetes/issues/92092
https://github.com/kubernetes/kubernetes/labels/committee%2Fproduct-security

for reference, the SECURITY_CONTACTS idea was announced here:
https://groups.google.com/forum/#!topic/kubernetes-dev/codeiIoQ6QE

instead of including individuals and given this is not part of GitHub
user automation, can we have the SECURITY_CONTACTS files direct users
towards mailing list email addresses where volunteers from SIGs can be
on rotation?

for example:
- SIG Foo can have a "sig-foo-security" mailing list.
- all repositories owned by SIG Foo can have "sig-foo-security"
present in SECURITY_CONTACTS.
- it would be up to the SIG to keep the security mailing list up-to-date.

the current method has a couple of issues:
- can be noisy if regular changes are required.
- a GitHub username *is not* really a security contact unless it
matches the local-part of an email address or a slack nickname (i'm
excluding communication on private GitHub repositories as a scenario).
- suffers from the same problem as OWNERS files; a person steps down
from working on the project and the enumerated contact is no longer
active.

lubomir
--

[Lubomir I. Ivanov]

forwarded to kubernetes-security-discuss:

[Benjamin Elder]

Moving usernames to a mailing list moves stepped down users etc. to the mailing list allowed subscribers (surely it wouldn't be a public read list...) instead of the file, I don't see how this actually solves the problem.

GitHub handle => email is straightforward.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-arch...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CAGDbWi9uNJLiV5FY%3DnCD9ANRbjCK58MmnKNiEXggOqNH1pn%3DQQ%40mail.gmail.com.

[Jordan Liggitt]

I agree we want to avoid having to maintain N additional private mailing lists.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CAOZRXm9bPnZ7%2BSfoxJ2d8yhGN%2B1BDquRNu6%2Bv_M%3DjCbqFMpz%3Dg%40mail.gmail.com.

[Lubomir I. Ivanov]

dropping kubernetes-security-discuss as it appears to be bouncing.

On Thu, 23 Jul 2020 at 07:04, Jordan Liggitt <lig...@google.com> wrote:
>
> I agree we want to avoid having to maintain N additional private mailing lists.

another option is just enumerating the SIG security contacts under
each SIG via a new field in "sigs.yaml" (of k/community):

example URL:
https://github.com/kubernetes/community/tree/master/sig-architecture#security-contacts

whether those are GitHub handles or email addresses is debatable [1],
but at least it provides aliasing.

>
> On Thu, Jul 23, 2020 at 12:00 AM 'Benjamin Elder' via kubernetes-sig-architecture <kubernetes-si...@googlegroups.com> wrote:
>>
>> Moving usernames to a mailing list moves stepped down users etc. to the mailing list allowed subscribers (surely it wouldn't be a public read list...) instead of the file, I don't see how this actually solves the problem.
>>
>> GitHub handle => email is straightforward.

here are the GitHub profiles of some of the existing PSC members. i
could not find their email right away (i could probably find it with
some research):
https://github.com/cji
https://github.com/joelsmith
https://github.com/lukehinds
https://github.com/micahhausler
https://github.com/swamymsft

taken from:
https://github.com/kubernetes/community/tree/master/committee-product-security#members

[1] does this mean that having an email address in the GitHub profile
is mandatory if one is a security contact?

lubomir
--

[Benjamin Elder]

SECURITY_CONTACTS is a file in a repo for a given project, I would assume that the contacts for the repo have commits in the repo (!) which makes it possible for PSC to obtain emails if/when they need them.

The PSC is contactable via other means and is not quite the same (org wide rather than project specific).

[Tim Allclair]

I agree that digging up emails for security contacts can be annoying, hence https://github.com/kubernetes/security/issues/56.

I think GitHub is working on some tools that will make this easier, but I don't know when they'll land. Those would also be per-repository, and there may be cases where we want finer granularity.

I like the idea of having sig security contacts as an escalation point when the security contacts are missing or unresponsive, but I think we could just escalate to the sig chairs in that case.

--

You received this message because you are subscribed to the Google Groups "kubernetes-sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-arch...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CAOZRXm9f%3D1Z8LVNWiPBY5FJwUSpfXtKrhb-zWS--MdNxZ7c%2BJw%40mail.gmail.com.

[Daniel Smith]

We could request that folks in SECURITY_CONTACTS files keep e.g. a github gist with their email & PGP public keys or whatever.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CADtktAWcrrHxnZuUwbeZRrMakd93C%2BO927EJiipFDF%3DM%2B%3Dp7rA%40mail.gmail.com.

[Tim Allclair]

I think this issue originally came about because SECURITY_CONTACTS is confusing. The intention is that it lists the people that the PSC should reach out to for escalation, but it could be misinterpreted as the people that vulnerabilities should be initially reported to (rather than secu...@kubernetes.io). I think that was the confusion that lead to most repos just listing the PSC members as the security contacts.

I propose that:

1. We get rid of the SECURITY_CONTACTS file. It is also confusing once we add SECURITY.md

2. We add a new _optional_ section to OWNERS files, something like `security-contacts:`

3. We default to contacting the approvers when security-contacts aren't specified. It is up to the PSC what depth to reach out to for approvers (probably not too much of a concern outside of k/k).

What do you think? I'm assuming the top level approvers are a pretty good proxy for security contacts in most cases. I know the owners can get out of date, but we already have some processes for keeping OWNERS up to date. This doesn't solve the private email problem though.

[Stephen Augustus]

I agree with all three.

For emails, perhaps we need tooling that can lookup an email address/GH username mapping based on https://github.com/cncf/gitdm?

-- Stephen

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CADtktAXoE02AyHjFF16fBj5g5ZozQfrpopEHNDpRZ%3Dt7kmt8Pw%40mail.gmail.com.

[Daniel Smith]

On Thu, Jul 23, 2020 at 11:54 AM Tim Allclair <tall...@google.com> wrote:

I think this issue originally came about because SECURITY_CONTACTS is confusing. The intention is that it lists the people that the PSC should reach out to for escalation, but it could be misinterpreted as the people that vulnerabilities should be initially reported to (rather than secu...@kubernetes.io).

Oh, yes, that is super misleading.

[Lubomir I. Ivanov]

On Thu, 23 Jul 2020 at 21:54, Tim Allclair <tall...@google.com> wrote:
>
> I think this issue originally came about because SECURITY_CONTACTS is confusing.

it can be confusing, indeed.

> The intention is that it lists the people that the PSC should reach out to for escalation, but it could be misinterpreted as the people that vulnerabilities should be initially reported to (rather than secu...@kubernetes.io). I think that was the confusion that lead to most repos just listing the PSC members as the security contacts.
>

i guess i already knew that (as it's clearly stated in all
SECURITY_CONTACTS files), but was giving PSC member GitHub profiles as
examples where email retrieval is not a click away.

> I propose that:
> 1. We get rid of the SECURITY_CONTACTS file. It is also confusing once we add SECURITY.md
> 2. We add a new _optional_ section to OWNERS files, something like `security-contacts:`
> 3. We default to contacting the approvers when security-contacts aren't specified. It is up to the PSC what depth to reach out to for approvers (probably not too much of a concern outside of k/k).
>
> What do you think? I'm assuming the top level approvers are a pretty good proxy for security contacts in most cases. I know the owners can get out of date, but we already have some processes for keeping OWNERS up to date.

i like this idea a lot.

> This doesn't solve the private email problem though.

i'm fine with having my email both at my GitHub profile and in an
OWNERS file, but i guess this is not true for everyone.
ref https://github.com/torvalds/linux/blob/master/MAINTAINERS

thanks
lubomir
--

[John Gardiner Myers]

On Thursday, July 23, 2020 at 11:54:31 AM UTC-7, Tim Allclair wrote:

3. We default to contacting the approvers when security-contacts aren't specified. It is up to the PSC what depth to reach out to for approvers (probably not too much of a concern outside of k/k).

 I was recently made an approver for a subproject. As a consequence I was added to that subproject's communication mechanism for security incidents. At no point was I informed of or asked to abide by the Embargo Policy. I only know about it because I read the (out of date) SECURITY_CONTACTS file.

While I believe it is reasonable to equate approvers with security contacts, I would suggest that this responsibility and the requirement to abide by the Embargo Policy be added to the approver section of https://github.com/kubernetes/community/blob/master/community-membership.md

[Tim Allclair]

Adding back +kubernetes-security-discuss (I updated the permissions so anyone can post). For the full context on the discussion so far, you can view the thread on kubernetes-sig-architecture: https://groups.google.com/d/topic/kubernetes-sig-architecture/0MUJBDGf3jg/discussion

@John - that's a good point. I like the idea of adding it to the approvers requirements, if we go that route.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-arch...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/58f55ff9-1cd9-4d18-9c27-395e232661a8o%40googlegroups.com.

[Lubomir I. Ivanov]

hello,

the security contacts issues in k/k seem to remain open and are marked
as frozen:
https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+label%3Acommittee%2Fproduct-security+%22Security+contacts%22

was there any further discussion on how to proceed?

On Thu, 23 Jul 2020 at 21:54, Tim Allclair <tall...@google.com> wrote:

>> I propose that:
>> 1. We get rid of the SECURITY_CONTACTS file. It is also confusing once we add SECURITY.md
>> 2. We add a new _optional_ section to OWNERS files, something like `security-contacts:`

>> 3. We default to contacting the approvers when security-contacts aren't specified. It is up to the PSC what depth to reach out to for approvers (probably not too much of a concern outside of k/k).
>>

>> What do you think? I'm assuming the top level approvers are a pretty good proxy for security contacts in most cases. I know the owners can get out of date, but we already have some processes for keeping OWNERS up to date.

like i mentioned, i think this is a good idea. i can help with PRs
around these efforts if this is how the security committee would like
to proceed?

i've also verified in k/test-infra that the field in some OWNERS files
"emeritus_approvers" is not tracked in a structure, which tells me
that there is no strict parsing of OWNERS files and a
"security_contacts:" field can be optionally added without updating
code in that repository.

so removing SECURITY_CONTACTS files would immediately enable the
fallback to approvers as security contacts.
the addition of "security_contacts:" can be optional and a matter of
documentation + notification to the mailing lists if the change comes
in action.

lubomir
--

[Tim Allclair]

@PSC - It looks like this was on the agenda for last weeks meeting, but I joined late and missed it. Were there any conclusions?

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-arch...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CAGDbWi9b3t5XRBfZkzFh8pLdYWOhFWD7O5TYDpBV_G%2BHsqk4fw%40mail.gmail.com.

[Lubomir I. Ivanov]

thank you, i can notify maintainers of the repositories that SIG
Cluster Lifecycle owns (quite a few) to remove the SECURITY_CONTACTS
files, but i'm assuming you are going to run automation using
something like "hub" across the whole GitHub orgs to file the PRs.

lubomir
--

> Thanks,
> Joel

> You received this message because you are subscribed to the Google Groups "kubernetes-security-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-security...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-security-discuss/CALXpagx7yWt1S4mU4ztrcH1wiic2NSBrwkAmAYeWG7cZ4NbA%2BA%40mail.gmail.com.

[Sam Fowler]

Very belated, but I finally circled back and made some progress on this:

https://github.com/kubernetes/security/issues/56#issuecomment-758518519

If the example PR I've made is agreeable, I can build on the demo script and create bulk PRs to update all OWNERS across the kubernetes org