-
Notifications
You must be signed in to change notification settings - Fork 231
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
OCPBUGS-34373: routes/custom-host permission update for externalCertificate #1754
OCPBUGS-34373: routes/custom-host permission update for externalCertificate #1754
Conversation
…icate * “create” is required to set spec.tls.externalCertificate on route creation * either “create” or “update” is required to update spec.tls.externalCertificate * Note: since the state of the external secret cannot be verified, even keeping the secret name unchanged, requires permission check. * NO PERMISSION is required to remove spec.tls.externalCertificate Signed-off-by: chiragkyal <ckyal@redhat.com>
Skipping CI for Draft Pull Request. |
@chiragkyal: This pull request references Jira Issue OCPBUGS-34373, which is invalid:
Comment The bug has been updated to refer to the pull request using the external bug tracker. In response to this:
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 openshift-eng/jira-lifecycle-plugin repository. |
/assign @alebedev87 @Miciah |
Signed-off-by: chiragkyal <ckyal@redhat.com>
/jira refresh |
@lihongan: This pull request references Jira Issue OCPBUGS-34373, which is valid. 3 validation(s) were run on this bug
Requesting review from QA contact: In response to this:
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 openshift-eng/jira-lifecycle-plugin repository. |
{ | ||
name: "key-added", | ||
host: "host", | ||
expected: "host", | ||
oldHost: "host", | ||
tls: &routev1.TLSConfig{Termination: routev1.TLSTerminationEdge, Key: "a"}, | ||
oldTLS: &routev1.TLSConfig{Termination: routev1.TLSTerminationEdge}, | ||
wildcardPolicy: routev1.WildcardPolicyNone, | ||
allow: false, | ||
errs: 1, | ||
}, | ||
{ | ||
name: "key-removed", | ||
host: "host", | ||
expected: "host", | ||
oldHost: "host", | ||
tls: &routev1.TLSConfig{Termination: routev1.TLSTerminationEdge}, | ||
oldTLS: &routev1.TLSConfig{Termination: routev1.TLSTerminationEdge, Key: "b"}, | ||
wildcardPolicy: routev1.WildcardPolicyNone, | ||
allow: false, | ||
// removing key info is allowed | ||
errs: 0, | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need these tests for the change you did or you just wanted to enhance the unit tests for other cases?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These tests are unrelated to the changes I made related to externalCertificate; I just wanted to enhance different test scenarios.
{ | ||
name: "certificate-added", | ||
host: "host", | ||
expected: "host", | ||
oldHost: "host", | ||
tls: &routev1.TLSConfig{Termination: routev1.TLSTerminationEdge, Certificate: "a"}, | ||
oldTLS: &routev1.TLSConfig{Termination: routev1.TLSTerminationEdge}, | ||
wildcardPolicy: routev1.WildcardPolicyNone, | ||
allow: false, | ||
errs: 1, | ||
}, | ||
{ | ||
name: "certificate-removed", | ||
host: "host", | ||
expected: "host", | ||
oldHost: "host", | ||
tls: &routev1.TLSConfig{Termination: routev1.TLSTerminationEdge}, | ||
oldTLS: &routev1.TLSConfig{Termination: routev1.TLSTerminationEdge, Certificate: "b"}, | ||
wildcardPolicy: routev1.WildcardPolicyNone, | ||
allow: false, | ||
// removing certificate info is allowed | ||
errs: 0, | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same question.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as #1754 (comment)
errs = append(errs, validateImmutableField(route.Spec.TLS.ExternalCertificate.Name, older.Spec.TLS.ExternalCertificate.Name, field.NewPath("spec", "tls", "externalCertificate"), routeTLSPermissionErrMsg)...) | ||
// since the state of the external secret cannot be verified, return error (even when secret name remains unchanged) | ||
// without performing immutability checks, if externalCertificate is set. | ||
errs = append(errs, field.Invalid(field.NewPath("spec", "tls", "externalCertificate"), route.Spec.TLS.ExternalCertificate, routeTLSPermissionErrMsg)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Which unit test covers this change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"external-certificate-unchanged-denied"
{
name: "external-certificate-unchanged-denied",
host: "host",
expected: "host",
oldHost: "host",
tls: &routev1.TLSConfig{Termination: routev1.TLSTerminationEdge, ExternalCertificate: &routev1.LocalObjectReference{Name: "a"}},
oldTLS: &routev1.TLSConfig{Termination: routev1.TLSTerminationEdge, ExternalCertificate: &routev1.LocalObjectReference{Name: "a"}},
wildcardPolicy: routev1.WildcardPolicyNone,
allow: false,
// permission is required even if referenced secret name remains unchanged
errs: 1,
opts: route.RouteValidationOptions{AllowExternalCertificates: true},
},
We need to remove the immutability check to catch the externalCertificate unchanged scenario, without having necessary permissions.
@@ -137,7 +137,7 @@ func certificateChangeRequiresAuth(route, older *routev1.Route, opts route.Route | |||
a.Key != b.Key | |||
|
|||
if opts.AllowExternalCertificates { | |||
if route.Spec.TLS.ExternalCertificate != nil || older.Spec.TLS.ExternalCertificate != nil { | |||
if route.Spec.TLS.ExternalCertificate != nil { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suppose this change is responsible for the note from the PR description:
Note: since the state of the external secret cannot be verified, even keeping the secret name unchanged, requires permission check.
I think this code deserves a comment with similar description.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The function godoc has a similar description. Let me know if we need to include anything else.
// Note: If (newer/updated) route uses externalCertificate, this function always returns true, as we cannot definitively verify if
// the content of the referenced secret has been modified. Even if the secret name remains the same,
// we must assume that the secret content is changed, necessitating authorization.
/approve Can I (doubt)? |
/lgtm |
/cc @Miciah |
/jira refresh |
@chiragkyal: This pull request references Jira Issue OCPBUGS-34373, which is valid. 3 validation(s) were run on this bug
Requesting review from QA contact: In response to this:
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 openshift-eng/jira-lifecycle-plugin repository. |
func ValidateHostExternalCertificate(ctx context.Context, new, older *routev1.Route, sarc routecommon.SubjectAccessReviewCreator, opts routecommon.RouteValidationOptions) field.ErrorList { | ||
|
||
if !opts.AllowExternalCertificates { | ||
// Return nil since the feature gate is off. | ||
// ValidateHostUpdate() is sufficient to validate | ||
// permissions. | ||
return nil | ||
} | ||
|
||
newTLS := new.Spec.TLS | ||
oldTLS := older.Spec.TLS | ||
if (newTLS != nil && newTLS.ExternalCertificate != nil) || (oldTLS != nil && oldTLS.ExternalCertificate != nil) { | ||
return routecommon.CheckRouteCustomHostSAR(ctx, field.NewPath("spec", "tls", "externalCertificate"), sarc) | ||
} | ||
|
||
return nil | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since ValidateHostExternalCertificate
is used in openshift-apiserver, removing its definition now could cause difficulties if someone else needs a change from library-go in openshift-apiserver and tries to bump it before you update openshift-apiserver not to use ValidateHostExternalCertificate
. That is:
- You remove
ValidateHostExternalCertificate
from library-go. - You don't have time to post the openshift-apiserver PR right away, or reviews get delayed.
- Meanwhile, someone else adds function xyz to library-go and bumps openshift-apiserver to get xyz.
- Building openshift-apiserver fails because
ValidateHostExternalCertificate
is not defined.
It would be safer to do the following:
- Update logic in library-go, but keep
ValidateHostExternalCertificate
(maybe add a// Deprecated
comment) so library-go can be bumped in openshift-apiserver without breaking anything. - Update code in openshift-apiserver not to use
ValidateHostExternalCertificate
. - Remove
ValidateHostExternalCertificate
from library-go.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the suggestion, and I agree that we should be doing the way you suggested above.
However, even if we keep ValidateHostExternalCertificate
definition, the unit tests present in the openshift-apiserver will complain due to the changes in validateTLSExternalCertificate
function because we are dropping custom-host
permission check from that function as well. There are fair amount of unit tests overlap between openshift-apiserver
and library-go, so updating logic in library-go requires immediate intervention (bump) in openshift-apiserver
as well.
If these weren't any unit tests in openshift-apiserver
, then it could have been much easier.
Need to resolve openshift/enhancements#1652 (comment). |
/approve Thanks! |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: alebedev87, chiragkyal, Miciah The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
@chiragkyal: all tests passed! Full PR test history. Your PR dashboard. 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-sigs/prow repository. I understand the commands that are listed here. |
@chiragkyal: Jira Issue OCPBUGS-34373: Some pull requests linked via external trackers have merged: The following pull requests linked via external trackers have not merged:
These pull request must merge or be unlinked from the Jira bug in order for it to move to the next state. Once unlinked, request a bug refresh with Jira Issue OCPBUGS-34373 has not been moved to the MODIFIED state. In response to this:
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 openshift-eng/jira-lifecycle-plugin repository. |
“create” is required to set
spec.tls.externalCertificate
on route creationeither “create” or “update” is required to update
spec.tls.externalCertificate
Note: since the state of the external secret cannot be verified, even keeping the secret name unchanged, requires permission check.
NO PERMISSION is required to remove
spec.tls.externalCertificate
EP changes OCPBUGS-34373: routes/custom-host permission update for externalCertificate enhancements#1652
The decision was taken based on openshift/origin#18177 (comment) discussion on custom-host permission and keep it identical with the existing
spec.tls.Certificate
field.