Description of problem: Once a custom TLS certificate has been configured for a route, the certificate cannot be updated. The error returned is: > The Route "nice" is invalid: spec.tls.certificate: Invalid value: "-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----": field is immutable Version-Release number of selected component (if applicable): 3.6 How reproducible: Confirmed Steps to Reproduce: Here's how to reproduce the issue: - Make sure you do not have the cluster-admin role assigned (CEE tested with "admin" role in a project) - Create a new project and deploy something and expose a route - Add a TLS certificate to the route Try to replace the certificate by the following means, all of which failed: - edit in the webgui via "Edit" - edit in the webgui via "Edit YAML" - edit on the CLI via "oc edit route ..." - edit on the CLI via "oc patch route/health -p '{"spec":{"tls":{"certificate":"-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----","key":"-----BEGIN RSA PRIVATE KEY-----\n...\n-----END RSA PRIVATE KEY-----"}}}'" Actual results: The Route "test" is invalid: spec.tls.certificate: Invalid value: "-----BEGIN CERTIFICATE-----\nggg\n-----END CERTIFICATE-----": field is immutable Expected results: Patch the route Additional info: Possibly related: https://github.com/openshift/origin/issues/15772 I checked the admin clusterrole and it appears it should be able to patch or edit routes: # oc describe clusterrole admin | grep route [create delete deletecollection get list patch update watch] [] [] [route.openshift.io ] [routes] [create] [] [] [route.openshift.io ] [routes/custom-host] [get list watch] [] [] [route.openshift.io ] [routes/status] [update] [] [] [route.openshift.io ] [routes/status]
The editing of tls fields falls under the routes/custom-host resource. The admin role is only allowed to create the fields, not update them (as shown above). So what is the request here? 1. Should we allow 'update' on routes/custom-host by default for admin clusterrole? 2. Should we not keep 'tls' in routes/custom-host purview? 3. Should we allow 'update' on routes/custom-host by default for edit clusterrole also? 4. Keep it as it is. On the field, any cluster-admin/system:admin can edit the admin role for a project. e.g. ''' $ oc edit clusterrole admin' .. .. - apiGroups: - route.openshift.io - "" attributeRestrictions: null resources: - routes/custom-host verbs: - create - update # <--- insert this verb .. .. '''
*** Bug 1528461 has been marked as a duplicate of this bug. ***
As the one working the other case attached to this bz, I think the expected result is that if you are able to edit things for a project (project admin or edit role for a project) you would be able to update the route to add/edit tls info. As you saw with the other bz (1528461), the current status is not acceptable because it means if you are not a cluster-admin (or similar) once you create a route that is it for that route, you would have to delete the route in order to make a secure one. I.e. 1 and 3 are the ideal I think
PR for the fix: https://github.com/openshift/origin/pull/18177 Note that the fix will not allow a user with 'edit' role to be able to update it. This PR will only allow the verb for the 'admin' of the project. i.e. #1 option, not #3 from comment#1
The bug is that you shouldn't have been able to add the custom certificate without having the permission. If you created that route on an older version of OpenShift, the administrator should have given the user permission to set TLS certificates. There was another bug fixed in 3.7 (I think) that may have fixed this for 3.6 (https://github.com/openshift/origin/pull/15551) TLS certificates are dangerous, and can cause routers to fail. Since we cannot control all possible router implementations, by default we do not allow TLS certificates to be set for "untrusted users". For instance, the F5 router or a custom router template, or older OpenShift routers may all allow any user to immediately break the entire router. The choice to block edit by default is to preserve safety for older users. Because this permission spans namespaces, neither project editor or project admin are safe by default. It is not safe to give those users the permission unless you are using a known safe router. To grant this permission to users, add the route/custom-host resource permission to the role, and only if your router is using extended certificate validation. If there is a 3.6 specific bug, we should address it based on whatever we fixed later. We cannot safely change the default role behavior. We could split the permission into two halves - certificates and custom hosts, but that adds additional complexity. Either way, decision to allow certs and decision to allow custom hosts is up to the admin, can't be done by default, and shouldn't be set.
Ok. Will the fix for this interpretation of the bug (remove the access to create the TLS 1if you can't edit it) affect existing cluster, perhaps through a "reconcile-cluster-roles" step? If so I could see this having potential impact on OpenShift Online and OpenShift Dedicated clusters. Adding Erich Rich, Narayanan Raghavan for input on steps we might need to take (banner, etc)
> The bug is that you shouldn't have been able to add the custom certificate without having the permission. The issue also is that 'admin' role has the rights to create, but does not have the rights to update. In that case, this PR is the right answer: https://github.com/openshift/origin/pull/18177 Clayton, confirm?
allowing updating hostnames means a user can update the hostname on an old route and take traffic from another namespace's already-established route.
New PR https://github.com/openshift/origin/pull/18312
Verified this bug on v3.9.0-0.47.0,now the route cert can be updated after created. 1. Create edge route oc create -f https://raw.githubusercontent.com/openshift-qe/v3-testfiles/master/routing/edge/route_edge.json 2. updated the cert by 'oc edit route' 3. check the route cert has been updated.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:0489
*** Bug 1590491 has been marked as a duplicate of this bug. ***
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 365 days