Re: [che-dev] Pre-existing workspace service account

[Serhii Leshchenko <sleshche@xxxxxxxxxx>]

> We could apply the special annotation on Che created resources, like: `org.eclipse.che/managed-by: che-server`...

There is recommended label app.kubernetes.io/managed-by in https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/#labels

On Tue, Jun 16, 2020 at 7:05 PM Ilya Buziuk <ibuziuk@xxxxxxxxxx> wrote:

@Ilya Buziuk Could you confirm that we're able to apply a needed annotation to already initialized user's namespaces?

for 'che-workspace' SA it should be possible to add extra annotation but would require cluster-wide tenant update - https://github.com/fabric8-services/fabric8-tenant/blob/master/environment/templates/fabric8-tenant-che-mt.yml#L48-L57

cc: @Alexey Kazakov  @Matous Jobanek could you please confirm?

On Tue, Jun 16, 2020 at 11:56 AM Serhii Leshchenko <sleshche@xxxxxxxxxx> wrote:

I'm +1 for the `let's make this work` approach.

> And we can use an optional annotation on the SA to change the behavior to "do not touch"

👍 Might be a solution

Prop:

- It does not introduce difficulty for admins to manage SA by themselves;

Cons:

- The current behavior is changed and existing installation might be affected but I'm not sure 

if we have such `managed SA` cluster except che.openshift.io which can be updated by us.

@Ilya Buziuk Could you confirm that we're able to apply a needed annotation to already initialized user's namespaces?

And in addition to Mario's proposal for cluster-admin managed SA and role/rolebinding:

We could apply the special annotation on Che created resources, like: `org.eclipse.che/managed-by: che-server`...

Prop: 

- it would be a bit clearer that admin is not supposed to touch it;

Cons:

- it might be tricky to apply that annotation on already existing installations.

We always may try to update SA, role, rolebinding and if we got 403 - then we don't propagate error but assume that

we're on the cluster where SA is managed by cluster-admin but not Che Server.

On Tue, Jun 16, 2020 at 2:11 AM Mario Loriedo <mario.loriedo@xxxxxxxxx> wrote:

I am +1 for the "let's make this work" approach. And we can use an optional annotation on the SA to change the behavior to "do not touch"

On Mon, Jun 15, 2020 at 2:47 PM Lukas Krejci <lkrejci@xxxxxxxxxx> wrote:

Hi all,

There is this behavior within the Che server that we always seem to do a
couple of circles around whenever someone hits some kind of problem in the
area.

The issue is this: Currently, we don't touch the workspace service account if
we find it already existing.

This means that the role bindings are not updated on it, nor are any
potentially missing roles created or updated, if we find them missing or
configured differently.

The reasoning behind this is that if we find a pre-existing SA in the
namespace we want to start a workspace in, we assume that the cluster admin
already did their homework and set up the permissions for Che the way they
want and need in their cluster.

We could argue in favor of the other behavior and update the service account
with the stuff we need regardless of whether it existed or not. This would be
more convenient, but in theory could hamper with the security constraints
imposed by the cluster admin.

WDYT? Do you favor the current "do not touch" approach or the more convenient
"let's make this work" approach?

Thanks,

Lukas


_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/che-dev

_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/che-dev

--

Serhii Leshchenko

SENIOR SOFTWARE ENGINEER

Red Hat 

--

ILYA BUZIUK

PRINCIPAL SOFTWARE ENGINEER

Red Hat

--

Serhii Leshchenko

SENIOR SOFTWARE ENGINEER

Red Hat