Skip to content
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

Default ABAC to off in GCE (for new clusters). #51367

Merged
merged 1 commit into from
Sep 19, 2017

Conversation

cjcullen
Copy link
Member

@cjcullen cjcullen commented Aug 25, 2017

What this PR does / why we need it:
Disables the legacy ABAC authorizer by default on GCE/GKE clusters using kube-up.sh. Existing clusters upgrading to 1.8 will keep their existing configuration.

Release note:

New GCE or GKE clusters created with `cluster/kube-up.sh` will not enable the legacy ABAC authorizer by default. If you would like to enable the legacy ABAC authorizer, export ENABLE_LEGACY_ABAC=true before running `cluster/kube-up.sh`.

@k8s-ci-robot k8s-ci-robot added size/XS Denotes a PR that changes 0-9 lines, ignoring generated files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. labels Aug 25, 2017
@k8s-github-robot k8s-github-robot added the release-note Denotes a PR that will be considered when it comes time to generate release notes. label Aug 25, 2017
@cjcullen
Copy link
Member Author

@kubernetes/sig-auth-pr-reviews

@k8s-ci-robot k8s-ci-robot added the sig/auth Categorizes an issue or PR as relevant to SIG Auth. label Aug 25, 2017
@cjcullen cjcullen assigned mikedanese and unassigned jszczepkowski Aug 25, 2017
@@ -1270,6 +1270,7 @@ function parse-master-env() {
REQUESTHEADER_CA_CERT_BASE64=$(get-env-val "${master_env}" "REQUESTHEADER_CA_CERT")
PROXY_CLIENT_CERT_BASE64=$(get-env-val "${master_env}" "PROXY_CLIENT_CERT")
PROXY_CLIENT_KEY_BASE64=$(get-env-val "${master_env}" "PROXY_CLIENT_KEY")
ENABLE_LEGACY_ABAC=$(get-env-val "${master_env}" "ENABLE_LEGACY_ABAC")
Copy link
Member

Choose a reason for hiding this comment

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

Does this set it to "" and prevent the defaulting in config-default?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, which means the only way to change this on an existing cluster is to modify the existing kube-env in metadata.

I'm not sure of a better way to handle updates. Either, we do this, and changing the existing value is kinda gross, or we go off of the config-default value, and we (possibly surprisingly) update the value on existing clusters. This felt like the less intrusive approach.

Copy link
Member

Choose a reason for hiding this comment

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

Is there a well defined procedure for changing existing cluster parameters generally?

Copy link
Member

Choose a reason for hiding this comment

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

we definitely should not update the value on existing clusters during upgrade. existing workloads should continue to run as-is on an upgraded cluster.

updating the default for new clusters is what I'd like to see, though the interaction between metadata env and the config-default.sh scripts is not clear to me (I can't tell which runs first, which informs the other, etc).

@cjcullen
Copy link
Member Author

@bgrant0607 since you had concerns about ABAC defaulting when we initially went for it :).

@bgrant0607 bgrant0607 added the release-note-action-required Denotes a PR that introduces potentially breaking changes that require user action. label Aug 28, 2017
@bgrant0607 bgrant0607 assigned liggitt and roberthbailey and unassigned jbeda and mikedanese Aug 28, 2017
@bgrant0607
Copy link
Member

The deprecation policy doesn't really cover this:
https://kubernetes.io/docs/reference/deprecation-policy/

Technically, kube-up is deprecated and not part of Kubernetes proper, but is part of the release bundle.

I'm ok with changing default behavior for new clusters at this point. RBAC has been well publicized and has been enabled by default for one minor release.

@liggitt
Copy link
Member

liggitt commented Aug 28, 2017

I agree with the intent of the PR, I'll defer to @roberthbailey on whether this change effectively accomplishes the following:

  • running kube-up without an expressed preference disables ABAC
  • running kube-up with ENABLE_LEGACY_ABAC set honors the setting
  • upgrading existing clusters preserve current settings from metadata

@roberthbailey
Copy link
Contributor

I'm confused by the title of this issue -- we recently removed gke support from kube-up and this PR only touches config files used by the gce implementation.

@cjcullen cjcullen changed the title Default ABAC to off in GCE/GKE (for new clusters). Default ABAC to off in GCE (for new clusters). Sep 11, 2017
@cjcullen
Copy link
Member Author

/retest

@cjcullen
Copy link
Member Author

/test pull-kubernetes-e2e-gce-etcd3

@cjcullen cjcullen added this to the v1.8 milestone Sep 12, 2017
@roberthbailey
Copy link
Contributor

Are we still hoping to get this in for 1.8?

@liggitt
Copy link
Member

liggitt commented Sep 14, 2017

comment at #51367 (comment) stands... it LGTM assuming the three scenarios described have been tested

@cjcullen
Copy link
Member Author

Just verified:

Creating a new cluster w/ cluster/kube-up.sh produces an apiserver w/ --authorization-mode=Node,RBAC (scenario 1)

Running cluster/gce/upgrade.sh -M -l on this cluster keeps the authorization mode w/o ABAC (scenario 3).

Modifying the metadata to set ENABLE_LEGACY_ABAC='true' and then running cluster/gce/upgrade.sh -M -l gets me a cluster w/ --authorization-mode=Node,RBAC,ABAC (scenario 3)

Creating a new cluster w/ ENABLE_LEGACY_ABAC='true' cluster/kube-up.sh produces an apiserver w/ --authorization-mode=Node,RBAC,ABAC (scenario 2)

Running cluster/gce/upgrade.sh -M -l on this cluster keeps the authorization mode w/ ABAC enabled (scenario 3).

@cjcullen
Copy link
Member Author

And yes, I think we still want this in for 1.8 (Our GCE tests already run w/ ABAC off).

@liggitt
Copy link
Member

liggitt commented Sep 14, 2017

Agree. CI has run with ABAC off since 1.6.

/lgtm

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Sep 14, 2017
@liggitt
Copy link
Member

liggitt commented Sep 14, 2017

One last question, does creating a 1.7 cluster populate metadata with ENABLE_LEGACY_ABAC=true?

@cjcullen
Copy link
Member Author

A 1.7 cluster with this script will set ENABLE_LEGACY_ABAC='false'. I think it might be even more confusing to version gate the setting (and I would have to do semver parsing in bash...). WDYT?

@cjcullen
Copy link
Member Author

/test pull-kubernetes-e2e-gce-bazel

@liggitt
Copy link
Member

liggitt commented Sep 15, 2017

A 1.7 cluster with this script will set ENABLE_LEGACY_ABAC='false'

I'm asking about a 1.7 cluster created with 1.7 scripts. Does metadata contain the environment variable set to true in that case?

@cjcullen
Copy link
Member Author

I'm asking about a 1.7 cluster created with 1.7 scripts. Does metadata contain the environment variable set to true in that case?

Yes

@liggitt
Copy link
Member

liggitt commented Sep 18, 2017

sounds good to me. @roberthbailey has approval

@roberthbailey
Copy link
Contributor

/approve

@mikedanese
Copy link
Member

/approve no-issue

@k8s-github-robot
Copy link

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: cjcullen, liggitt, mikedanese, roberthbailey

Associated issue requirement bypassed by: mikedanese

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these OWNERS Files:

You can indicate your approval by writing /approve in a comment
You can cancel your approval by writing /approve cancel in a comment

@k8s-github-robot k8s-github-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Sep 18, 2017
@k8s-github-robot
Copy link

/test all

Tests are more than 96 hours old. Re-running tests.

@k8s-github-robot
Copy link

Automatic merge from submit-queue (batch tested with PRs 48970, 52497, 51367, 52549, 52541). If you want to cherry-pick this change to another branch, please follow the instructions here..

@k8s-github-robot k8s-github-robot merged commit 7b8d7de into kubernetes:master Sep 19, 2017
@k8s-ci-robot
Copy link
Contributor

k8s-ci-robot commented Sep 19, 2017

@cjcullen: The following tests failed, say /retest to rerun them all:

Test name Commit Details Rerun command
pull-kubernetes-unit e44c876 link /test pull-kubernetes-unit
pull-kubernetes-node-e2e e44c876 link /test pull-kubernetes-node-e2e

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. lgtm "Looks good to me", indicates that a PR is ready to be merged. release-note Denotes a PR that will be considered when it comes time to generate release notes. release-note-action-required Denotes a PR that introduces potentially breaking changes that require user action. sig/auth Categorizes an issue or PR as relevant to SIG Auth. size/XS Denotes a PR that changes 0-9 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

9 participants