REQUEST: New Slack private channel #security-release-team

[justaugustus]

GitHub Username:
@justaugustus @kubernetes/release-managers @kubernetes/product-security-committee

Slack Username:
justaugustus

What Type of Request is it (Channel, User Group, Bot, Token, or Webhook)?
Private channel

Name of Requested Resource:
#security-release-team

Description of Request:
Proposing a new private channel to spur tighter feedback loop between PSC and Release Managers when discussing vulns, security releases, and overall improvements to our processes.

Serves improvement around kubernetes/sig-release#896 and kubernetes/committee-security-response#63.

/assign @mrbobbytables @alejandrox1

[liggitt]

Are we comfortable using a private channel in a publicly-joinable slack instance to discuss details of vulnerabilities and security releases? The ability to select duplicate usernames is slightly concerning, and I'm unsure the degree to which admins and app integrations have visibility into channel content.

[joelsmith]

That's a good point. It seems like the PSC should have guidelines on what is and isn't okay to discuss on Slack. I see this channel being used more for release coordination and not for the discussion of specific details around the issues. I like the idea of a channel, but only if people understand what is and isn't okay to discuss there.

[mrbobbytables]

@liggitt slack admins cannot administer private channels if they are not invited into it (the channel creator is auto-added on initial creation). Admins cannot view/manage/pull the data from dms or private channels. It's actually been kind of a pain point for us as administrators and one of the reasons they are rarely created.

Workspace owners (currently @parispittman and @caniszczyk), CAN pull logs etc, but it requires some extra hoops to jump through.

Regarding the slack IDs, if you want to be 100% certain on the people in there, you can check their slack memberID (view profile -> more) to verify they are the right person. Those are unique and cannot be duplicated.

[tallclair]

I'm comfortable with adding the channel as long as it's explicitly for release coordination, and we agree not to discuss vulnerability specifics on the channel. Maybe we can add a channel header as a reminder.

One (non-blocking) concern is that this is one more place we need to audit access of. To that end:

1. It should be documented in our on/offboarding docs
2. We (PSC) should add a process for a regular audit of access everywhere that has vulnerability information. See Establish audit process for information access committee-security-response#97

[coderanger]

To echo from Slack, @tallclair and @justaugustus will be the delegated moderators for this space, just in case. Given the private nature, full moderation coverage doesn't seem required so I'm happy with that from the Slack Admin side.

[coderanger]

Channel created and initial users added.

/close

[k8s-ci-robot]

@coderanger: Closing this issue.

In response to this:

Channel created and initial users added.

/close

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.