[docs] Enabling authn/authz

[whitlockjc]

What would your suggestion be for enabling authn/authz when using kube-solo? I can think of a few ways that might work but before doing extra work or doing it in an unsuggested way, I figured I would ask. There are really two topics here:

1. Taking an existing kube-solo VM and altering it so that the apiserver's startup has the appropriate flags
2. Possibly making it so that kube-solo itself can be provided with these details using an environment variable or some configuration file and kube-solo will just use these upon startup

Thoughts?

[rimusz]

currently k8s starts via fleet units which allows easily make changes redeploy the changed unit.
we can try option 1).
never used authn/authz before, can you provide the kube master settings needed for the change, so i will look how to implement it
thanks

[whitlockjc]

Here are the pertinent links to the Kubernetes docs (this isn't an RTFM but since they've got documentation, it seemed simpler):

• Authentication: http://kubernetes.io/docs/admin/authentication/
• Authorization: http://kubernetes.io/docs/admin/authorization/

The problem I'm trying to solve first is I want to provide the necessary --oidc-* options to the apiserver upon startup so that I can enable token-based OpenID Connect authentication.

I realize that this might not be something you want to support within kube-solo but if we can work together on an approach, I don't mind writing the documentation so that others could do this. Being the optimist I am, I do bet there is some way we can make kube-solo pick up some configuration (environment variable, config file, ...) from the host system on an opt-in basis.

[whitlockjc]

@rimusz If I've got kube-solo already running, how should I go about changing the fleet unit and getting it deployed? I've not used fleet directly so I'm not even sure how to start. I'm hoping I can use a kube-solo distribution and that I don't have to build/run a custom one. If that is the case, do you mind pointing me in the right direction on getting started?

[whitlockjc]

I just realized kube-solo ships with a fleet UI so I will start there.

[rimusz]

@whitlockjc fleet might be gone from the next version, just do the systemd unit and add it to cloud-init file

[whitlockjc]

So as things stand now, I could update ~/kube-solo/fleet/kube-apiserver.service and restart the VM to alter how the k8s apiserver is started. But if fleet goes away, I'd instead update ~/kube-solo/cloud-init/user-data to do this by creating a systemd unit. Is this correct? I'm just trying to make sure I understand things correctly.

[rimusz]

@whitlockjc the latest version v0.8.7 has no fleet anymore, so update user-data file

[whitlockjc]

I've had trouble updating to v0.8.7 for now so until that is fixed, what is the appropriate flow to doing this? I've tried altering ~/kube-solo/fleet/kube-apiserver.service and bouncing the VM but it doesn't seem to pick those changes up. I've tried the reload/update fleet unit menubar item and it just overwrites my changes. What is the suggested approach to do this with fleet since it's the only way to do it locally for me right now?

[rimusz]

@whitlockjc update the kube-apiserver.service in fleet folder, then it that folder run ' fleetctl destroy kube-apiserver.service && fleetctl start kube-apiserver.serrvice' and the kube-apiserver will redeployed

[rimusz]

@whitlockjc corectl.app v0.2.1 works on macOS 10.10, so you can use it with the latest kube-solo v0.8.7. So update the cloud-init there to check authn/authz

[whitlockjc]

Thanks a lot @rimusz. I did finally figure out the fleetctl process to get this working. Now that I'm switching to the cloud-init approach, how do I follow the same flow to update the apiserver and redeploy it after changes?

[rimusz]

no worries @whitlockjc
just edit the kube-solo/cloud-init/user-data file and then halt and up, that's it.
Can authn/authz stuff be enabled all the time and not used?

[whitlockjc]

I think it's possible to keep it enabled all the time but it would likely not make sense. I wanted to test the OIDC support for authentication and now that I've done that, I want to switch back to the default kube-solo approach using a certificate. I do think that if you want a simple kube-solo, you don't want extra authn/authz. But if you find the need to test or use authn/authz, knowing how to enable it would be pretty useful.

[rimusz]

ok, then just drop your updated user-data file and instructions how to use to me by email, so if there are such needs I have it. :)
thanks

[whitlockjc]

You got it. I'll go through the process to make sure the halt, up process just works and then we could easily document this as a So You Need a Custom API Server section or something. ;)

[rimusz]

awesome, thanks

[McCodeman]

@whitlockjc I'm also interested in enabling RBAC. Have you posted your procedure anywhere? I specifically have a need for some pods to be able to interact with the K8s API (currently they are getting denied). After enabling RBAC, my thought was to create a service account with the appropriate roles bound to it that given them access to query the API. Thanks for your input. -- One additional thing... can the certificate approach allow a container process to access the API?

[whitlockjc]

Enabling authn/authz is the same. You update your ~/kube-solo/cloud-init/user-data to provide the necessary enablement flags to the kube-apiserver.service. Have you tried this?