Lokomotive: Add a supported way to configure OIDC authentication in kube-apiserver

[iaguis]

To have users authenticate to the cluster using Dex+Gangway we ask them to configure the API server with some OIDC flags.

We tell users to add these flags directly to the API Server daemonset/deployment. This means whenever users run lokoctl cluster apply again they will be overwritten.

We should expose those flags to the user.

Refs:

• Adding arbitrary extra arguments to the API Server: https://github.com/kinvolk/lokomotive/issues/122

[invidian]

Seems like a duplicate of #279.

[iaguis]

True, since this is more detailed and we don't really depend on #123 as mentioned in #279 I think I'll keep this.

[invidian]

Please note, that there is a PR opened, which partially implements required functionality: #182. We need to change parameters exposed to the user in this PR. Since we agreed, that we won't allow setting _any_ flag to kube-apiserver, what parameters should we add?

We need to set following flags:

--oidc-issuer-url=https://dex.YOUR.CLUSTER.DOMAIN.NAME
--oidc-client-id=gangway
--oidc-username-claim=email
--oidc-groups-claim=groups

So should we add following parameters to all platforms?:

oidc_issuer_url = ""
oidc_client_id = ""
oidc_username_claim = ""
oidc_groups_claim = ""

Should those parameters have some default values? Or maybe we only want to expose subset of them?

The alternative would be to wrap them in a oidc block, which would allow to make it more DRY across the platforms. Something like:

oidc {
  issuer_url = ""
  client_id = ""
  username_claim = ""
  groups_claim = ""
}

[ipochi]

@invidian @iaguis @rata @johananl

Can we get a consensus around this one ?

1. Introduce a new block oidc in parallel to cluster block.
2. Add the requisite fields in cluster block.

[johananl]

In my opinion we want to add the necessary OIDC-related knobs as fields in the existing cluster configuration block and make all of them optional if possible. I'm also open to grouping these fields into a block, but that block should be nested under cluster, not parallel to it.

Rationale:

• OIDC params are cluster attributes. They have no meaning separately from a cluster. Therefore, they should live under cluster.
• Any "maintainer concerns" are of a lower priority than UX. If we can make things DRY-er without producing an unintuitive config structure - great. Until we find a way to do that, let's tolerate some duplication.
• Any field which can be made optional should be, combined with a sane default. This reduces the number of knobs the user needs to deal with which has a very high impact on UX.

[ipochi]

In my opinion we want to add the necessary OIDC-related knobs as fields in the existing cluster configuration block and make all of them optional if possible. I'm also open to grouping these fields into a block, but that block should be nested under cluster, not parallel to it.

Rationale:

• OIDC params are cluster attributes. They have no meaning separately from a cluster. Therefore, they should live under cluster.
• Any "maintainer concerns" are of a lower priority than UX. If we can make things DRY-er without producing an unintuitive config structure - great. Until we find a way to do that, let's tolerate some duplication.
• Any field which _can_ be made optional should be, combined with a sane default. This reduces the number of knobs the user needs to deal with which has a very high impact on UX.

1. oidc block inside cluster sounds reasonable to me.
2. Agree on the same defaults accompanied with documentation.

[iaguis]

I agree with oidc block inside cluster and sane defaults :+1:

[johananl]

SGTM. Just to clarify what I meant by "optional":

• When the oidc block isn't specified the deployment should work.
• When the oidc block is specified and an optional field (if any) in the oidc block isn't specified, the deployment should work.

[ipochi]

SGTM. Just to clarify what I meant by "optional":

• When the oidc block isn't specified the deployment should work.
• When the oidc block is specified and an optional field (if any) in the oidc block isn't specified, the deployment should work.

@johananl

When the oidc block isn't specified , we don't configure the apiserver with optional oidc arguments, in effect we do nothing.

However when the oidc block is specified and all/some fields are not provided then we use sane defaults.

[iaguis]

Fixed by #182