Skip to content

releng: Enable elevated privileges for Release Managers on SIG Release GCP projects #434

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

Merged
merged 2 commits into from
Oct 30, 2019
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
83 changes: 79 additions & 4 deletions groups/groups.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -484,6 +484,79 @@ groups:
- [email protected]
- [email protected] # sock-puppet for testing

- email-id: [email protected]
name: k8s-infra-release-admins
description: |-
ACL for Release Engineering subproject owners (partial admin access to Release GCP projects)
https://git.k8s.io/sig-release/release-managers.md
settings:
AllowExternalMembers: "true"
WhoCanJoin: "INVITED_CAN_JOIN"
WhoCanViewMembership: "ALL_MEMBERS_CAN_VIEW"
WhoCanViewGroup: "ALL_MEMBERS_CAN_VIEW"
WhoCanDiscoverGroup: "ALL_IN_DOMAIN_CAN_DISCOVER"
WhoCanInvite: "ALL_MANAGERS_CAN_INVITE"
WhoCanAdd: "ALL_MANAGERS_CAN_ADD"
WhoCanApproveMembers: "ALL_MANAGERS_CAN_APPROVE"
WhoCanModifyMembers: "OWNERS_AND_MANAGERS"
WhoCanModerateMembers: "OWNERS_AND_MANAGERS"
ReconcileMembers: "true"
owners:
- [email protected]
- [email protected]
- [email protected]

- email-id: [email protected]
name: k8s-infra-release-editors
description: |-
ACL for Patch Release Team and Branch Managers (edit access to Release GCP projects)
https://git.k8s.io/sig-release/release-managers.md
settings:
AllowExternalMembers: "true"
WhoCanJoin: "INVITED_CAN_JOIN"
WhoCanViewMembership: "ALL_MEMBERS_CAN_VIEW"
WhoCanViewGroup: "ALL_MEMBERS_CAN_VIEW"
WhoCanDiscoverGroup: "ALL_IN_DOMAIN_CAN_DISCOVER"
WhoCanInvite: "ALL_MANAGERS_CAN_INVITE"
WhoCanAdd: "ALL_MANAGERS_CAN_ADD"
WhoCanApproveMembers: "ALL_MANAGERS_CAN_APPROVE"
WhoCanModifyMembers: "OWNERS_AND_MANAGERS"
WhoCanModerateMembers: "OWNERS_AND_MANAGERS"
ReconcileMembers: "true"
owners:
- [email protected]
- [email protected]
- [email protected]
members:
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]

- email-id: [email protected]
name: k8s-infra-release-viewers
description: |-
ACL for Release Manager Associates (view access to Release GCP projects)
https://git.k8s.io/sig-release/release-managers.md
settings:
AllowExternalMembers: "true"
WhoCanJoin: "INVITED_CAN_JOIN"
WhoCanViewMembership: "ALL_MEMBERS_CAN_VIEW"
WhoCanViewGroup: "ALL_MEMBERS_CAN_VIEW"
WhoCanDiscoverGroup: "ALL_IN_DOMAIN_CAN_DISCOVER"
WhoCanInvite: "ALL_MANAGERS_CAN_INVITE"
WhoCanAdd: "ALL_MANAGERS_CAN_ADD"
WhoCanApproveMembers: "ALL_MANAGERS_CAN_APPROVE"
WhoCanModifyMembers: "OWNERS_AND_MANAGERS"
WhoCanModerateMembers: "OWNERS_AND_MANAGERS"
ReconcileMembers: "true"
owners:
- [email protected]
- [email protected]
- [email protected]

- email-id: [email protected]
name: k8s-infra-sig-release-prototype
description: |-
Expand Down Expand Up @@ -1005,9 +1078,9 @@ groups:
- email-id: [email protected]
name: release-managers-private
description: |-
Release managers for security releases. Membership should include release leads and patch release managers.

Membership by release leads and patch release managers.
Private communications for SIG Chairs, Patch Release Team, and Branch Managers.
(internal scheduling and security release coordination)
https://git.k8s.io/sig-release/release-managers.md
settings:
AllowExternalMembers: "true"
WhoCanJoin: "INVITED_CAN_JOIN"
Expand Down Expand Up @@ -1039,7 +1112,9 @@ groups:
- email-id: [email protected]
name: release-managers
description: |-
Release Managers communications
Release Managers communications.
Includes all Release Managers.
https://git.k8s.io/sig-release/release-managers.md
settings:
AllowExternalMembers: "true"
WhoCanJoin: "INVITED_CAN_JOIN"
Expand Down
137 changes: 137 additions & 0 deletions infra/gcp/ensure-release-projects.sh
Original file line number Diff line number Diff line change
@@ -0,0 +1,137 @@
#!/usr/bin/env bash
#
# Copyright 2019 The Kubernetes Authors.
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

# This script is used to ensure Release Managers have the appropriate access
# to SIG Release GCP projects.

set -o errexit
set -o nounset
set -o pipefail

SCRIPT_DIR=$(dirname "${BASH_SOURCE[0]}")
. "${SCRIPT_DIR}/lib.sh"

function usage() {
echo "usage: $0 [project...]" > /dev/stderr
echo "example:" > /dev/stderr
echo " $0 # do all release projects" > /dev/stderr
echo " $0 k8s-staging-release-test # just do one" > /dev/stderr
echo > /dev/stderr
}

# NB: Please keep this sorted.
PROJECTS=(
k8s-staging-release-test
Copy link
Member

Choose a reason for hiding this comment

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

currently these are covered by the other ensure-* scripts. Should we a) drop them from those, b) add this logic to those, c) refactor to make the overlap clear?

k8s-release-test-prod
)

if [ $# = 0 ]; then
# default to all release projects
set -- "${PROJECTS[@]}"
fi

ADMINS="[email protected]"
WRITERS="[email protected]"
VIEWERS="[email protected]"

for PROJECT; do
color 3 "Configuring: ${REPO}"

# The names of the buckets
STAGING_BUCKET="gs://${PROJECT}" # used by humans
Copy link
Member

Choose a reason for hiding this comment

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

This is the piece I want to discuss most - Do we want these projects "governed" by 2 ensure scripts? This overlaps directly with the other scripts, which means it will drift.

There's a particular set of semantics that we ascribe to a "staging project" and a "prod project". You are adding on to that, clearly, but it's not clear if you are changing more than that. In other words - should we make a clean break and remove these release projects from the other scripts? Or should we build on those?

For example, this script could do something like:

# First ensure that the project is a normal staging project
"${ROOT}/ensure-staging-project.sh" release-test
# Now apply customizations for release staging

If it helps, we can refactor the existing scripts to make this more obvious. I knew this was likely to come up, so we it should not be hard - we left room.

GCB_BUCKET="gs://${PROJECT}-gcb" # used by GCB
ALL_BUCKETS=("${STAGING_BUCKET}" "${GCB_BUCKET}")

# Make the project, if needed
color 6 "Ensuring project exists: ${PROJECT}"
ensure_project "${PROJECT}"

for group in ${ADMINS} ${WRITERS} ${VIEWERS}; do
# Enable admins to use the UI
color 6 "Empowering ${group} as project viewers"
empower_group_as_viewer "${PROJECT}" "${group}"
done

# Every project gets a GCR repo

# Enable container registry APIs
color 6 "Enabling the container registry API"
enable_api "${PROJECT}" containerregistry.googleapis.com

# Push an image to trigger the bucket to be created
color 6 "Ensuring the registry exists and is readable"
ensure_gcr_repo "${PROJECT}"

# Enable GCR admins
color 6 "Empowering GCR admins"
empower_gcr_admins "${PROJECT}"

# Enable GCR writers
for group in ${ADMINS} ${WRITERS}; do
color 6 "Empowering ${group} to GCR"
empower_group_to_gcr "${PROJECT}" "${group}"
done

# Every project gets some GCS buckets

# Enable GCS APIs
color 6 "Enabling the GCS API"
enable_api "${PROJECT}" storage-component.googleapis.com

for BUCKET in "${ALL_BUCKETS[@]}"; do
color 3 "Configuring bucket: ${BUCKET}"

# Create the bucket
color 6 "Ensuring the bucket exists and is world readable"
ensure_public_gcs_bucket "${PROJECT}" "${BUCKET}"

# Enable admins on the bucket
color 6 "Empowering GCS admins"
empower_gcs_admins "${PROJECT}" "${BUCKET}"

# Enable writers on the bucket
for group in ${ADMINS} ${WRITERS}; do
color 6 "Empowering ${group} to GCS"
empower_group_to_gcs_bucket "${group}" "${BUCKET}"
done
done

# Enable GCB and Prow to build and push images.

# Enable GCB APIs
color 6 "Enabling the GCB API"
enable_api "${PROJECT}" cloudbuild.googleapis.com

# Let project writers use GCB.
for group in ${ADMINS} ${WRITERS}; do
color 6 "Empowering ${group} as GCB editors"
empower_group_for_gcb "${PROJECT}" "${group}"
done

# Let prow trigger builds and access the scratch bucket
color 6 "Empowering Prow"
empower_prow "${PROJECT}" "${GCB_BUCKET}"

# Enable KMS APIs
color 6 "Enabling the KMS API"
enable_api "${PROJECT}" cloudkms.googleapis.com

# Let project admins use KMS.
color 6 "Empowering ${ADMINS} as KMS admins"
empower_group_for_kms "${PROJECT}" "${ADMINS}"

color 6 "Done"
done
17 changes: 17 additions & 0 deletions infra/gcp/lib.sh
Original file line number Diff line number Diff line change
Expand Up @@ -287,6 +287,23 @@ function empower_group_for_gcb() {
--role roles/serviceusage.serviceUsageConsumer
}

# Grant KMS admin privileges to a principal
# $1: The GCP project
# $2: The group email
function empower_group_for_kms() {
if [ $# -lt 2 -o -z "$1" -o -z "$2" ]; then

Choose a reason for hiding this comment

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

Should we make that stricter by doing something like the below?

if [ $# -ne 2 -o -z "$1" -o -z "$2" ]; then

I saw, that other funcs here allow additional arguments, but that might just be a c&p "issue" from cases where additional optional arguments are allowed (e.g. empower_group_to_gcr or empower_gcr_admins).

Copy link
Member

Choose a reason for hiding this comment

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

this is probably a good idea, but I'm OK to let this PR go in and fix it up across the board.

echo "empower_group_for_kms(project, group) requires 2 arguments" >&2
return 1
fi
project="$1"
group="$2"

gcloud \
projects add-iam-policy-binding "${project}" \
--member "group:${group}" \
--role roles/cloudkms.admin
}

# Grant privileges to prow in a staging project
# $1: The GCP project
# $2: The GCS scratch bucket
Expand Down