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

tls update will be possible with 'create' permissions on custom-host #18312

Merged
merged 1 commit into from
Feb 5, 2018

Conversation

rajatchopra
Copy link
Contributor

@openshift-ci-robot openshift-ci-robot added the size/M Denotes a PR that changes 30-99 lines, ignoring generated files. label Jan 26, 2018
@openshift-ci-robot openshift-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jan 26, 2018
@rajatchopra
Copy link
Contributor Author

@liggitt PTAL

@@ -214,14 +214,37 @@ func (s routeStrategy) validateHostUpdate(ctx apirequest.Context, route, older *
if hostChanged {
Copy link
Contributor

Choose a reason for hiding this comment

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

this isn't quite what was described in #18177 (comment):

  1. check update if the host has changed, and if false, disallow any changes
  2. if host hasn't changed but certs have, check "create", and if false, disallow changes
  3. allow changes

I think we should only run the update custom-host SAR (the one above) if hostChanged

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@liggitt It implements the logic as described. Although this code does an extra check for 'update' always, it is to prevent a case where someone has an 'update' permission but does not have 'create'. We should allow that case to be able to update TLS certs.
Review again please.

Copy link

@pravisankar pravisankar left a comment

Choose a reason for hiding this comment

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

LGTM

@pravisankar
Copy link

@smarterclayton can you please review this pr? (@liggitt is on pto this week)
I think the current implementation matches with what you suggested in #18177 (comment)

@knobunc
Copy link
Contributor

knobunc commented Jan 31, 2018

@rajatchopra We'll need to amend openshift/openshift-docs#7398 when we get this merged.

@enj
Copy link
Contributor

enj commented Feb 1, 2018

Please copy the entire requirement from @smarterclayton at #18177 (comment) as a comment into this part of the code and reference it throughout the checks. No one will remember in a few months how we came to this conclusion.

@openshift/sig-security

@tnozicka
Copy link
Contributor

tnozicka commented Feb 1, 2018

this is exactly what I need to run http://github.com/tnozicka/openshift-acme as regular user (hopefully the last part)

lgtm but agree with @enj to have that extended comment in code

@tnozicka
Copy link
Contributor

tnozicka commented Feb 1, 2018

/retest

@tnozicka
Copy link
Contributor

tnozicka commented Feb 1, 2018

/cherrypick release-3.7

@openshift-cherrypick-robot

@tnozicka: once the present PR merges, I will cherry-pick it on top of release-3.7 in a new PR and assign it to you.

In response to this:

/cherrypick release-3.7

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.

@tnozicka
Copy link
Contributor

tnozicka commented Feb 1, 2018

/cherrypick release-3.8

@openshift-cherrypick-robot

@tnozicka: once the present PR merges, I will cherry-pick it on top of release-3.8 in a new PR and assign it to you.

In response to this:

/cherrypick release-3.8

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.

@knobunc
Copy link
Contributor

knobunc commented Feb 2, 2018

For posterity, the comment at #18177 (comment) by @smarterclayton that led to this approach was:

original intent was to control three things

  1. Can you request a custom host ("create" "routes/custom-host")
  2. Can you change custom host ("update" "routes/custom-host")
  3. Are you allowed to set TLS certificates on a route

Online only wanted 1, because 2 allows you to steal routes, and 3 allows
you to break some routers. In general, out of the box we don't want to
give "update" "routes/custom-host" to anyone - I was wrong above. We also
don't want to give everyone access to update tls certificates.

When we implemented this, we went through a long chain of argument on 3 -
should we even allow you to set TLS certs when you don't have permission to
create custom hosts. Setting a publicly facing TLS cert doesn't have a ton
of value if your admin isn't letting you have a custom name, and the admin
is encouraged to use the default cert. But even if the admin didn't have a
default cert, if they could still (via the API with a higher privileged
operation) set certs, they would be safe. So we made it so that create
custom-host controlled setting TLS certs on the route, which solved the
online problem and preserved the less strictly tenanted use case as well -
an admin bot that wanted to set certs could be given create-host.

The set of people who should be able to update a host on a route is only
"update" "routes/custom-host". The set of people who should be able to
update tls certificates on the route are:

  1. people who can create custom-hosts (they could delete and recreate the
    route, and we shouldn't be abusive)
  2. people who can update custom-hosts (they can steal other people's
    routes, and so we're not worried about them)

The check for updating TLS certificates should involve checking for either
of those permissions. Strictly speaking:

  1. "update" "routes/custom-host" should allow unrestricted changes to routes
  2. "create" "routes/custom-host" should allow setting host on creation and
    changing tls certificate
  3. without those, you should be unable to set either host or tls certificate

We should update the strategy check for "update" to

  1. check update if the host has changed, and if false, disallow any changes
  2. if host hasn't changed but certs have, check "create", and if false,
    disallow changes
  3. allow changes

@knobunc
Copy link
Contributor

knobunc commented Feb 5, 2018

/lgtm

@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Feb 5, 2018
@openshift-ci-robot
Copy link

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: knobunc, rajatchopra

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

@openshift-merge-robot
Copy link
Contributor

/test all [submit-queue is verifying that this PR is safe to merge]

@openshift-merge-robot
Copy link
Contributor

Automatic merge from submit-queue (batch tested with PRs 18422, 18312).

@openshift-merge-robot openshift-merge-robot merged commit bb140ad into openshift:master Feb 5, 2018
@openshift-cherrypick-robot

@tnozicka: new pull request created: #18459

In response to this:

/cherrypick release-3.7

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.

@openshift-cherrypick-robot

@tnozicka: new pull request created: #18460

In response to this:

/cherrypick release-3.8

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.

openshift-merge-robot added a commit to openshift/origin-web-console that referenced this pull request Feb 6, 2018
Automatic merge from submit-queue.

Allow users to edit route TLS if they can create custom hosts

Console change for openshift/origin#18312
Closes #2699

/assign @jwforres 

/hold
because the upstream change hasn't merged
@rajatchopra rajatchopra deleted the tls_admit_bug branch February 6, 2018 21:05
@enj
Copy link
Contributor

enj commented Feb 14, 2018

@knobunc it would be helpful to actually address the comments before merging the code.

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. component/routing lgtm Indicates that a PR is ready to be merged. sig/security size/M Denotes a PR that changes 30-99 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

9 participants