Re: in OpenShift 4.2, /apis is not accessible to anonymous users. Workarounds?

[David Eads]

Yes, this is out of upstream, based on downstream choices we made five
years ago.

This behavior is not considered a bug.  When anonymous authentication is
enabled, you will only get a 401 if presenting an invalid token or expired
certificate.  When connecting anonymously, your connection successfully
authenticated, it is not a 401 condition.  Your successfully authenticated
connection (successful as anonymous), attempted to access a resource which
it did not have access to, it is forbidden, getting a 403.

On Thu, Oct 3, 2019 at 11:18 AM Ben Parees  wrote:

>
>
> On Thu, Oct 3, 2019 at 10:52 AM David Eads  wrote:
>
>> There is no plan to switch to 401.
>>
>
> Would plans be created if a BZ were opened?  Or this is an outright
> rejection of ever changing it because it's not deemed incorrect (or because
> "it's an api now and we can't change it")
>
> (Also i assume this is coming out of upstream?)
>
>
>
>>
>> On Thu, Oct 3, 2019 at 10:44 AM Jean-Francois Maury 
>> wrote:
>>
>>> According to the spec, it's wrong to return 403 in this case. Please re
>>> read my wording from the spec.
>>> Should I understand that there is no plan at all to switch to 401 ?
>>>
>>> Jeff
>>>
>>> On Thu, Oct 3, 2019 at 3:46 PM David Eads  wrote:
>>>
>>>> The 403 is intentional.  The user has been authenticated as anonymous,
>>>> so a 401 isn't returned.  Kubernetes and OpenShift both return 403 when a
>>>> user (even anonymous) attempts to access a forbidden resource regardless of
>>>> whether it even exists.
>>>>
>>>> On Wed, Oct 2, 2019 at 4:06 PM Jean-Francois Maury 
>>>> wrote:
>>>>
>>>>> We are trying to adapt our library but found the following problem:
>>>>> when we issue a call to /apis or some of the discovery endpoint without
>>>>> authentication info; OCP returns 403 instead of 401.
>>>>> According to the HTTP spec,403 should not be repeated and
>>>>> authentication will not help (see
>>>>> https://tools.ietf.org/html/rfc2616#section-10.4.4)
>>>>>
>>>>> So is it on purpose or is this going to be fixed ?
>>>>>
>>>>> Jeff
>>>>>
>>>>> On Tue, Oct 1, 2019 at 5:56 PM Andre Dietisheim 
>>>>> wrote:
>>>>>
>>>>>> Hi Akram
>>>>>>
>>>>>> Thanks for the answer. Insightful.
>>>>>> For now we can't easily switch libraries given the extent of usage
>>>>>> and amount of work to migrate.
>>>>>>
>>>>>> Cheers
>>>>>> André
>>>>>> Am 01.10.19 um 16:34 schrieb Akram Ben Aissi:
>>>>>>
>>>>>> Hi André,
>>>>>>
>>>>>> indeed this is the new default. And, historically, because of a CVE
>>>>>> raising an issue about it, dropping discovery of /api has been removed 
>>>>>> but
>>>>>> then temporary restored in 4.1 and removed in 4.2.
>>>>>> See this https://bugzilla.redhat.com/show_bug.cgi?id=1711533
>>>>>>
>>>>>> On the Jenkins plugins we were about to fix similar issues, cause
>>>>>> /oapi was deprecated in OCP 4.2 . We depends on kubernetes-client Java
>>>>>> library which fixed this.
>>>>>> https://github.com/fabric8io/kubernetes-client/issues/1587 and
>>>>>> follow the different PR. If you depend on this library also, maybe you 
>>>>>> have
>>>>>> your fix in a recent version.
>>>>>>
>>>>>> Otherwise, IIRC, the eclipse plugin required credentials (or a token)
>>>>>> to connect to openshift server, so in your case, you maybe "just" need to
>>>>>> use them to then get the endpoints.
>>>>>>
>>>>>> Akram
>>>>>>
>>>>>>
>>>>>> Le mar. 1 oct. 2019 à 15:38, Andre Dietisheim 
>>>>>> a écrit :
>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>> In OpenShift 4.2 "/apis" started only being accessible to authorized
>>>>>>> users. This causes troubles for the Eclipse tooling and the java
>>>>>>> client
>>>>>>> library openshift-restclient-java
>>>>>>> (https://github.com/openshift/openshift-r

Re: in OpenShift 4.2, /apis is not accessible to anonymous users. Workarounds?

[David Eads]

There is no plan to switch to 401.

On Thu, Oct 3, 2019 at 10:44 AM Jean-Francois Maury 
wrote:

> According to the spec, it's wrong to return 403 in this case. Please re
> read my wording from the spec.
> Should I understand that there is no plan at all to switch to 401 ?
>
> Jeff
>
> On Thu, Oct 3, 2019 at 3:46 PM David Eads  wrote:
>
>> The 403 is intentional.  The user has been authenticated as anonymous, so
>> a 401 isn't returned.  Kubernetes and OpenShift both return 403 when a user
>> (even anonymous) attempts to access a forbidden resource regardless of
>> whether it even exists.
>>
>> On Wed, Oct 2, 2019 at 4:06 PM Jean-Francois Maury 
>> wrote:
>>
>>> We are trying to adapt our library but found the following problem: when
>>> we issue a call to /apis or some of the discovery endpoint without
>>> authentication info; OCP returns 403 instead of 401.
>>> According to the HTTP spec,403 should not be repeated and authentication
>>> will not help (see https://tools.ietf.org/html/rfc2616#section-10.4.4)
>>>
>>> So is it on purpose or is this going to be fixed ?
>>>
>>> Jeff
>>>
>>> On Tue, Oct 1, 2019 at 5:56 PM Andre Dietisheim 
>>> wrote:
>>>
>>>> Hi Akram
>>>>
>>>> Thanks for the answer. Insightful.
>>>> For now we can't easily switch libraries given the extent of usage and
>>>> amount of work to migrate.
>>>>
>>>> Cheers
>>>> André
>>>> Am 01.10.19 um 16:34 schrieb Akram Ben Aissi:
>>>>
>>>> Hi André,
>>>>
>>>> indeed this is the new default. And, historically, because of a CVE
>>>> raising an issue about it, dropping discovery of /api has been removed but
>>>> then temporary restored in 4.1 and removed in 4.2.
>>>> See this https://bugzilla.redhat.com/show_bug.cgi?id=1711533
>>>>
>>>> On the Jenkins plugins we were about to fix similar issues, cause /oapi
>>>> was deprecated in OCP 4.2 . We depends on kubernetes-client Java library
>>>> which fixed this.
>>>> https://github.com/fabric8io/kubernetes-client/issues/1587 and follow
>>>> the different PR. If you depend on this library also, maybe you have your
>>>> fix in a recent version.
>>>>
>>>> Otherwise, IIRC, the eclipse plugin required credentials (or a token)
>>>> to connect to openshift server, so in your case, you maybe "just" need to
>>>> use them to then get the endpoints.
>>>>
>>>> Akram
>>>>
>>>>
>>>> Le mar. 1 oct. 2019 à 15:38, Andre Dietisheim  a
>>>> écrit :
>>>>
>>>>> Hi
>>>>>
>>>>> In OpenShift 4.2 "/apis" started only being accessible to authorized
>>>>> users. This causes troubles for the Eclipse tooling and the java
>>>>> client
>>>>> library openshift-restclient-java
>>>>> (https://github.com/openshift/openshift-restclient-java) which tries
>>>>> to
>>>>> discover endpoints before authenticating.
>>>>>
>>>>> Thus my question(s):
>>>>>
>>>>> * Is this the new default?
>>>>> * if this restriction is deliberate, what's the reasoning behind it?
>>>>> * Is there a workaround?
>>>>>
>>>>> Thanks for your answers!
>>>>> André
>>>>>
>>>>> ___
>>>>> dev mailing list
>>>>> dev@lists.openshift.redhat.com
>>>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>>>>>
>>>> ___
>>>> dev mailing list
>>>> dev@lists.openshift.redhat.com
>>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>>>>
>>>
>>>
>>> --
>>>
>>> Jeff Maury
>>>
>>> Manager, DevTools
>>>
>>> Red Hat EMEA <https://www.redhat.com>
>>>
>>> jma...@redhat.com
>>> @RedHat <https://twitter.com/redhat>   Red Hat
>>> <https://www.linkedin.com/company/red-hat>  Red Hat
>>> <https://www.facebook.com/RedHatInc>
>>> <https://www.redhat.com>
>>> <https://redhat.com/summit>
>>> ___
>>> dev mailing list
>>> dev@lists.openshift.redhat.com
>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>>>
>>
>
> --
>
> Jeff Maury
>
> Manager, DevTools
>
> Red Hat EMEA <https://www.redhat.com>
>
> jma...@redhat.com
> @RedHat <https://twitter.com/redhat>   Red Hat
> <https://www.linkedin.com/company/red-hat>  Red Hat
> <https://www.facebook.com/RedHatInc>
> <https://www.redhat.com>
> <https://redhat.com/summit>
>
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: in OpenShift 4.2, /apis is not accessible to anonymous users. Workarounds?

[David Eads]

The 403 is intentional.  The user has been authenticated as anonymous, so a
401 isn't returned.  Kubernetes and OpenShift both return 403 when a user
(even anonymous) attempts to access a forbidden resource regardless of
whether it even exists.

On Wed, Oct 2, 2019 at 4:06 PM Jean-Francois Maury 
wrote:

> We are trying to adapt our library but found the following problem: when
> we issue a call to /apis or some of the discovery endpoint without
> authentication info; OCP returns 403 instead of 401.
> According to the HTTP spec,403 should not be repeated and authentication
> will not help (see https://tools.ietf.org/html/rfc2616#section-10.4.4)
>
> So is it on purpose or is this going to be fixed ?
>
> Jeff
>
> On Tue, Oct 1, 2019 at 5:56 PM Andre Dietisheim 
> wrote:
>
>> Hi Akram
>>
>> Thanks for the answer. Insightful.
>> For now we can't easily switch libraries given the extent of usage and
>> amount of work to migrate.
>>
>> Cheers
>> André
>> Am 01.10.19 um 16:34 schrieb Akram Ben Aissi:
>>
>> Hi André,
>>
>> indeed this is the new default. And, historically, because of a CVE
>> raising an issue about it, dropping discovery of /api has been removed but
>> then temporary restored in 4.1 and removed in 4.2.
>> See this https://bugzilla.redhat.com/show_bug.cgi?id=1711533
>>
>> On the Jenkins plugins we were about to fix similar issues, cause /oapi
>> was deprecated in OCP 4.2 . We depends on kubernetes-client Java library
>> which fixed this.
>> https://github.com/fabric8io/kubernetes-client/issues/1587 and follow
>> the different PR. If you depend on this library also, maybe you have your
>> fix in a recent version.
>>
>> Otherwise, IIRC, the eclipse plugin required credentials (or a token) to
>> connect to openshift server, so in your case, you maybe "just" need to use
>> them to then get the endpoints.
>>
>> Akram
>>
>>
>> Le mar. 1 oct. 2019 à 15:38, Andre Dietisheim  a
>> écrit :
>>
>>> Hi
>>>
>>> In OpenShift 4.2 "/apis" started only being accessible to authorized
>>> users. This causes troubles for the Eclipse tooling and the java client
>>> library openshift-restclient-java
>>> (https://github.com/openshift/openshift-restclient-java) which tries to
>>> discover endpoints before authenticating.
>>>
>>> Thus my question(s):
>>>
>>> * Is this the new default?
>>> * if this restriction is deliberate, what's the reasoning behind it?
>>> * Is there a workaround?
>>>
>>> Thanks for your answers!
>>> André
>>>
>>> ___
>>> dev mailing list
>>> dev@lists.openshift.redhat.com
>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>>>
>> ___
>> dev mailing list
>> dev@lists.openshift.redhat.com
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>>
>
>
> --
>
> Jeff Maury
>
> Manager, DevTools
>
> Red Hat EMEA 
>
> jma...@redhat.com
> @RedHat    Red Hat
>   Red Hat
> 
> 
> 
> ___
> dev mailing list
> dev@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: Stop docker processes created by "oc cluster up"

[David Eads]

Yes, I would.  Depending on what you change, other containers/pods may need
to change.

On Mon, Mar 26, 2018 at 1:18 PM, Charles Moulliard 
wrote:

> So, do you recommend to use "oc cluster up" and "oc cluster down" even
> when we store existing configs "--use-existing-config=true" to stop/start
> openshift = docker ps ?
>
> On Mon, Mar 26, 2018 at 7:03 PM, Jean-Francois Maury 
> wrote:
>
>> oc cluster down ?
>>
>> Le lun. 26 mars 2018 à 19:00, Charles Moulliard  a
>> écrit :
>>
>>> Hi,
>>>
>>> When we use "oc cluster up" command, then openshift is started as docker
>>> containers (origin, router, registry + console) that we could stop/start
>>> using command "docker stop|start origin"
>>>
>>> The command "docker start origin" works very well as 7 docker ps are
>>> created to bootstrap the origin cluster
>>> - k8s_registry_docker-registry-1-w7c5r_default_c265ed3e-30c8-1
>>> 1e8-8a68-080027b2fb11_3
>>> - k8s_POD_docker-registry-1-w7c5r_default_c265ed3e-30c8-11e8-
>>> 8a68-080027b2fb11_2
>>> - k8s_router_router-1-dxzkh_default_c23e1d4d-30c8-11e8-8a68-
>>> 080027b2fb11_3
>>> - k8s_webconsole_webconsole-74df8f7c9-s6wxx_openshift-web-cons
>>> ole_c11f9613-30c8-11e8-8a68-080027b2fb11_2
>>> - k8s_POD_router-1-dxzkh_default_c23e1d4d-30c8-11e8-8a68-080027b2fb11_2
>>> - k8s_POD_webconsole-74df8f7c9-s6wxx_openshift-web-console_c11
>>> f9613-30c8-11e8-8a68-080027b2fb11_2
>>> - origin
>>>
>>> But when we use "docker stop origin", only the "origin" process is
>>> stopped
>>>
>>> Is there a trick to stop all the docker processes and not only "origin
>>>
>>> Regards
>>>
>>> Charles
>>> ___
>>> dev mailing list
>>> dev@lists.openshift.redhat.com
>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>>>
>>
>
> ___
> dev mailing list
> dev@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>
>
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

openshift/api and openshift/client-go are authoritative

[David Eads]

As of https://github.com/openshift/origin/pull/17477, h
ttps://github.com/openshift/api and https://github.com/openshift/client-go are
the authoritative source of the OpenShift API types and the OpenShift
external clients.  The external types and go client are no longer present
in https://github.com/openshift/origin.  This makes it possible to interact
with an OpenShift cluster without trying to vendor openshift/origin and it
changes the way that API changes are merged.

To make an API change in 3.8+:

   1. open a pull with the external types to openshift/api and get it
   reviewed, approved, and merged
   2. bump the vendored dependencies in openshift/client-go, regenerate
   (make generate build), and get it merged.
   3. bump the vendored dependencies in openshift/origin
   (hack/update-deps.sh), update your internal types, and start serving your
   new API.

For forks, you will have to merge into the appropriate branches of the
various repositories.
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

openshift/origin now vendors using glide

[David Eads]

We have just merged a pull which updates openshift/origin to use glide
instead of godep for vendoring.  Because of the particulars of vendoring
and picking patches for kubernetes, we will continue to use a helper script
called `hack/update-deps.sh` to run `glide update --strip-vendor`, but the
logic is simpler and the results are more reliable and much faster.

As we work through exactly what needs to be pinned for openshift, what
branches/tags we should pin to, and what should float with k8s.io/kubernetes,
you may find that updating particular packages ripple more than expected.
When that happens, try to make a decision about whether these dependencies
fall into the yours, mine, or ours bucket with kubernetes and make a
determination about pinning them.  When in doubt, tag openshift/sig-master,
we have some experience vendoring against kubernetes.
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Kubernetes 1.7 rebase merged

[David Eads]

The Kuberenetes 1.7.0 rebase for OpenShift 3.7 merged into master last
night (https://github.com/openshift/origin/pull/15234).  In addition to
bringing in the new Kubernetes features, there are a few notable
changes/issues.


   1. go 1.8 is now required to build
   2. The unidling proxy is currently disabled.  We have an issue to
   re-enable it: https://github.com/openshift/origin/issues/15101
   3. Builds using proxies have a problem with go 1.8, being fixed here:
   https://github.com/openshift/origin/pull/15071
   4. The list of known post-rebase tasks are here:
   
https://github.com/openshift/origin/issues?q=is%3Aissue+is%3Aopen+label%3Akind%2Fpost-rebase


Thanks to everyone who helped land this one quickly to make sure we start
3.7 in a good spot.
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

API types moving packages

[David Eads]

https://github.com/openshift/origin/pull/14843 moves our API types from
`pkg//api` to `pkg//apis/`.  This bring us in line
with the rest of the community.  Kubernetes uses this structure and various
generators and tools expect it.  It is also the recommendation for
aggregated API server projects.  It is important to merge this change into
3.6 so that bugs that are fixed in 3.7 will be reasonable to pick back into
3.6 without significant re-review.

We're continuing to separate by group directly underneath `pkg` to try to
keep our API groups separate going forward, separating our admission,
serving, and controller concerns.  The duplicate `` in the package
name is a result of this, but is more tolerable than trying to combine
unrelated API groups together to avoid it.

There are going to be some non-conflicting conflicts as a result of this
change.  I've rekicked test jobs for the first pulls in the queue. Check
your jobs to see if you're hitting a compile failure.

David Eads
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: Update ssl certs

[David Eads]

I'm not aware of any plans to support a cross-namespace references for
namespace scoped resources.  As for routes in particular, openshift routes
don't even have secret references, it's embedded right there in the type.
The only way I'd know to do it is a label selected `oc get` (btw, label
selected patch would be a really cool idea), then iterate through and issue
`oc patch` or `oc replace`.

On Thu, Mar 17, 2016 at 2:51 PM, Philippe Lafoucrière <
philippe.lafoucri...@tech-angels.com> wrote:

> Hi,
>
> We need to update a ssl certificate used in many projects. This is
> generally handled by puppet, but with openshift I don't see a way to update
> several routes at once.
> Is there something in the roadmap to declare certificates like secrets at
> a higher level, usable in various projects?
> I understand it would require authorization per project, but at least, we
> would be able to update all the site at once, instead of each route
> individually.
>
> Thanks
>
> ___
> dev mailing list
> dev@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>
>
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev