Route's new admission routes/custom-host doesn't work for legacy API

[tnozicka]

caused by: #13905

I am using legacy API and, after the aforementioned change, attempts to create a route fail on permissions with:
spec.host: Forbidden: you do not have permission to set the host field of the route

Full log is here: https://travis-ci.org/tnozicka/openshift-acme/jobs/244432395#L1211

I have already tried adding

  - routes/custom-host
  - routes/status

to the cluster role https://github.com/tnozicka/openshift-acme/blob/ceb941e145d0a3fa1bcf073cdca58f84837db203/deploy/clusterrole.yaml#L12-L13 but it doesn't help

This breaks openshift-acme project for Openshift 3.6. (Works fine with earlier versions.) Reported in tnozicka/openshift-acme#8

tested with openshift/origin:v3.6.0-alpha.2
(works fine with openshift/origin:v1.4.1 and openshift/origin:v1.5.1)

[tnozicka]

ping @knobunc (maybe also @liggitt)

[liggitt]

you need the permission in the route.openshift.io API group

[tnozicka]

@liggitt even if I don't use the API group at all? I use legacy API. Other cluster rules work fine just with "" (legacy API)

[tnozicka]

My point here is that if Routes are in legacy API and simultaneously in the new API group you should be fine with specifying just the one you use - here it is legacy API. (I could try to specify the API group too as a workaround.) But this seems buggy unless I am misinterpreting how auth works.

[liggitt]

The "custom-host" check is done internally by the API server and is unrelated to the URL you used to request the route

[ValentinFunk]

@tnozicka is there a way around this issue?
Can't use openshift-acme on the dev preview :(

[tnozicka]

@kamshak I have updated the cluster role to specify API group although we use legacy API only - so to me that's a hack but it works

[adelton]

@tnozicka, what are the exact high level steps to reproduce the issue?

Should merely following the steps from https://github.com/tnozicka/openshift-acme/blob/master/README.md

oc login -u system:admin
oc adm policy add-cluster-role-to-user acme-controller system:serviceaccount:acme:default
oc create -fhttps://github.com/tnozicka/openshift-acme/raw/master/deploy/{clusterrole,deploymentconfig-letsencrypt-staging,service}.yaml

trigger the issue?

[tnozicka]

@adelton we already hacked it by adding this line https://github.com/tnozicka/openshift-acme/blob/master/deploy/clusterrole.yaml#L7 so you would have to remove it. (But it should work even without it because we use only legacy API.)

[adelton]

@tnozicka, thanks. So executing the above steps should currently give me running Pod and that's the success criteria. Is that correct?

[tnozicka]

@adelton

• modify the cluster role in the create step to remove the api group
• create a Route like The server rejected our request due to an error in our request tnozicka/openshift-acme#8 (comment) or https://github.com/tnozicka/openshift-acme/blob/master/examples/routes/mydomain.io.yaml

that should be enough I think

success criteria would be that you wan't see the error in controller pod logs

[tnozicka]

@adelton if you are trying to fix this I think the SARs (like https://github.com/openshift/origin/pull/13905/files#r122653328) are wrong because they test only against route API group

[adelton]

I confirm that I've reproduced correct behaviour on 3.5 and failing behaviour on 3.6 and 3.7.

[adelton]

@smarterclayton, as the author of #13905 which introduced routes/custom-host in route.openshift.io and added the check -- what expectation is there about this working without route.openshift.io API group set?

IOW, do we ask everyone to do something like tnozicka/openshift-acme@d1f45fe from now on and is that expected?

[liggitt]

IOW, do we ask everyone to do something like tnozicka/openshift-acme@d1f45fe from now on and is that expected?

Yes. #13905 added that permission to the default roles that allow modifying routes automatically. Custom roles that want to allow setting custom hostnames on routes need to add the API group and permission.

[adelton]

Thanks @liggitt. I guess that would make this issue notabug/wontfix/working-as-expected then.

Or do we maybe want this spelled out in some documentation (and if yes, which one)?

[tnozicka]

For the record, I think it is logically wrong for a user to have to specify an API group in the role when he is using only legacy API (and isn't supposed to even know about groups).

[adelton]

The other point of view might be that functionality got hardened in later versions and if you want to enable the new routes/custom-host, it cannot be done with merely legacy API, it has to be done with route.openshift.io.

[smarterclayton]

The legacy API is dead - we'll continue to support it, but we won't be adding new features to it. Part of the reason is that ONLY the new APIs can be accessed by kubernetes extension capabilities, so we need to be nudging people to move to the new API.

[adelton]

Per justification by @smarterclayton, I'm going to close this issue since the behaviour that you experience is expected starting with 3.6.

[zonArt]

Hi,

Sorry for hijacking an already closed issue (and maybe not that much related to my current issue). I have a simple question: it's about the clusterrole edit, why are the apiGroups not set by default ? It's breaking a lot of in place stuff which were working quite well (with version 1.5 and with fabric8 maven plugin). Is this on purpose that users with edit role cannot anymore call the API ?

[liggitt]

it's about the clusterrole edit, why are the apiGroups not set by default

they are:

origin/test/testdata/bootstrappolicy/bootstrap_cluster_roles.yaml

Lines 1325 to 1331 in b65ef46

	- apiGroups:
	- ""
	- route.openshift.io
	resources:
	- routes/custom-host
	verbs:
	- create

if you are upgrading from a previous release, you need to reconcile cluster roles to ensure default roles are up to date

[zonArt]

@liggitt Hi, thanks for your reply, this was actually my initial thoughts and I did reconcile the cluster roles with no effect and that's exactly the whole point. I actually modified the edit role initially (removed the ability to create pvc) and when I did reconcile the role this ability came back (making me think the reconciliation worked just fine) however the apiGroups were still not set.

[adelton]

@zonArt, if it looks like the reconciliation does not fully work, could you please file separate issue for that, with full details of what you started with and what commands you run and what was the result, expected and actual? Thanks.