In Openshift: usage of Endpoints mechanism

[Samusername]

Hi!

I would like to use "endpoints" mechanisms in Patroni and (Zalando) postgres-operator, in Openshift.
Link to patroni documentation.
I would like to try to avoid the mentioned "ConfigMap" alternative.
"ConfigMap" alternative is almost "deprecated", and may be more unsafe/instable, according to documentations.

Usage of endpoints gives an error in Opensfhit, when Patroni DB cluster is tried to be started up.
The error looks like following:
"message":"endpoints \"acid-upgrade-test\" is forbidden: endpoint address <x.y.z.w> is not allowed","reason":"Forbidden"
See also:
zalando/postgres-operator#1702

If we give more "heavy" "admin" types of permissions,
in an own namespace,
then the DB cluster works also in Openshift.
Other types of permissions do not help. We have tried all kinds of other combinations.

We would like to try to avoid the "heavy" types of permissions. And we would like to give only limited permissions instead.

Latest comment from Red Hat contains following, regarding usage in Openshift:

""I will recommend you to check feasibility of this deployment on OpenShift. Because its your (users) responsibility to have supported stuff on OpenShift, if you face any issue with these type of custom configurations on OpenShift platform you have to resolve them.""
They also recommend to discuss with experts who develop the functionalities (in Patroni, and maybe in postgres-operators).

And, from Red Hat:
""it's unlikely that for a non-supported component we change the Endpoint working in OpenShift since Endpoint working is at the core k8s/OCP functionality altogether""

Red Hat does not plan to add more specific "verbs" to allow the type of patching of endpoints, in Opensfhit, currently.
So, they are asking the Open source component to change the mechanisms.
Or then we would need to use the more unsafe ConfigMaps alternatve. ConfigMaps alternative is "almost deprecated" (according to documentations of Zalando postgres-operator).
Then, there is the workaround alternative, of using wider admin type of permissions.

Could this be solved by some means?

[CyberDem0n]

Could this be solved by some means?

No, either service account has admin privileges and endpoints what allows writing Pod IPs to subsets of the endpoint, or you have to use config maps.

[Samusername]

In Openshift,

Addition permissions to following K8s resources works / helps.

• endpoints/restricted
• endpointslices/restricted

Not only for endpoints, but for above resources also.

endpoints/restricted has been mentioned in following ticket also, regarding patroni ( on a timescale github page ), in 2020:
timescale/helm-charts#91

endpoints/restricted has been mentioned also in a Red Hat ticket:
https://access.redhat.com/solutions/6969387
( Question, in that Red Hat ticket, concerned modification of endpoints. Although only creation is among the mentioned verbs there in the resolution. )

So, then the more like deprecated ConfigMap setup would not need to be used. -- So, then, it is possible use the default setup: the "Endpoints" setup, in Openshift also, with more precise powerful permissions.