Cloud Foundry CF on K8s Forum, 30 Nov 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Cloud Foundry On Kubernetes Working Group Forum [Nov 30]

Description

Recording from the CF on K8s Working Group Forum call held on 30th Nov 2021.

A

All right, the recording, let me start again uh welcome to everyone. That's here. Thank you for attending uh for anyone that's new here. This is the cloud foundry on kubernetes working group forum. That's an area for anyone to discuss any topics they want to bring up regards uh to any projects in the kubernetes space that are cloud-funded related.

A

um So I'm gonna drop a link to a document in the chat and people can fill. uh Look at that. uh If you have any other topics, you'd like to add to it, drop them in chat, I can add them onto the document and we can go from there.

A

So just give me one moment to pull those up.

A

A

So dropping that link in chat right now.

A

I don't currently have any topics there, um but I'll give it a couple minutes. So we can think about that.

A

I see a few more people are joining as well, so that'll be good to have a little bit of preamble time.

A

All right, uh I don't see any topics popping up right now, but uh we can also run this as just a completely open forum. If anyone has anything they'd like to discuss initially off the bat. Otherwise, we can just sort of like talk about what has been going on uh in the space.

B

Hey bird rock, I wanted to uh just get some understanding about um some of the kubernetes work with the cfcli. um I saw a few updates on github. I also saw some stuff on slack pop-up, so I'm not entirely sure what it is. um So I'd really appreciate some understanding of what that actually is.

A

Sure um I can feel that or tim if you want to feel that that's fine too. Let me know I.

C

Can take it if.

A

C

Yeah, so, basically um in terms of actual behavior, we do not expect changes on the cli, because we basically aim at implementing the same api as cfo vms, so the cli should just straight out work.

C

The thing we deviated from the thing in which we we deviated from cfon vms is authentication uh because we basically uh we're trying to get the cfcli to authenticate using kubernetes native ways of authenticating instead of bringing in ua and in its way of authenticating, which means we had to change the cli to teach it how to authenticate in a kubernetes native way, and we achieve that by reusing code that comes from a library called clientgo, which is the one the cube cattle is based on.

C

So basically this, if we we've managed to get the cfcli to authenticate to kubernetes by leveraging the user's um cubeconfig and which means, if, if you have a cluster with any of the any provider, that provider usually provides a way to generate a cube config, they usually ship. These, like proprietary clis, like google, does amazon, does microsoft, etc.

C

Once you've generated the cube config with that tool, the cfci will be able to just consume that config to to talk to the cluster, which is basically, we are leveraging kubernetes authentication to authenticate against our api, which is pretty cool.

C

um Every operation that the api will perform will be performed on behalf of the user, because the cli will send over the authentication information that is needed by the api to then call the actual kubernetes api and uh yeah. But this means that basically any cluster you can authenticate to uh with cubecastle you'll be able to authenticate too with cfcli.

C

So that was the change it was not like. It was quite a few lines of code because we had to change quite a few bits, but in the end the only change is in how we authenticate anything else is unchanged.

B

ah Thanks for that, so just to follow up to that- and I hope I'm not interrupting any other topics that folks have. uh But what does it mean in terms of behavior and I'll? Give you an example, so I have a team of let's say four or five um developers who are going to be interacting with the cf interface right.

B

So uh previously they did not have to gain access to the kubernetes clusters, because if they authenticated with the cf endpoint that will automatically lead um that will automatically allow them to push apps to um a cloud foundry foundation somewhere remote. um Does that behavior change in any way? So does this mean that they'll require access to both the kubernetes cluster, as well as the cloud foundry endpoints or um what? What? What is that behavior like.

C

There is no distinction between kubernetes users and cloud foundry users anymore. It's just the same user base and in the same spirit, we at some point want people to be able to consume cf, both via the api shim, that the thing we've been concentrating on lately or via our custom resource definitions, so that distinction is just not in place anymore.

C

So previously, I guess with cfo kate's you had ua running, so you had a user base that was inside ua's database and you so you could add someone to the ua use base and people could use. It would be able to use cf via those users and then cf, okay, via irini, created containers on cloud on on kubernetes, with with its own privileged user.

C

Now what's happening is that operations are being performed as your kubernetes user. So you log in to your kubernetes cluster as a kubernetes user, and then the cli will communicate your credentials to the api which will use them to act. On your behalf on the cluster there's exceptions to this, there is operations that just can't be performed on behalf of the user, like just by using the user's credentials.

C

So there are things where, like we fill in the gaps, uh there are places where, like we have to fill in the gaps with some privileged credentials, uh but overall, most operations will just be half them, be like happen on behalf of the user, using the user's credential credentials that get sent over by the cli.

C

uh So we kind of did removed that layer all together the authorization most of the authorization will also happen basically via kubernetes raw based access control. So we will. We aim to recreate the same permissions that cf has for different roles via role and roles and road bindings in kubernetes, so that basically consuming cf via the api or the crds should be pretty much the same even in terminal in terms of permissions.

C

If the concern is that you want to like constrain your users, to only be able to do cf things and not do anything else on the cluster, then you you have to. I guess, uh do that via the kubernetes tools, so restrict access to only the namespaces uh created by the cloud foundry.

C

This is a slightly tricky, because cloudfoundry will create namespaces dynamically when you, for example, as an admin, create spaces and create orgs, uh but in the end, just by creating the user and then as an admin, creating spaces and orgs and adding roles. Just like you did on cloud foundry on vms the things you just work out and your users, your users should not have any permission on the rest of the kubernetes clusters, because those roles will be set up to only give permissions to the user on the namespaces created and managed by cloud foundry.

C

So you should be fine.

B

Got it yeah thanks so much for uh clarifying just.

A

Awesome that was uh great for the people that are just joining us or that are uh listening to this discussion may not know the context. This discussion was centered around the uh cf kate's controllers, repo, and I can drop a link into that which is a project. That's ongoing to sort of re-envision the cf experience on top of kubernetes so giving that nice sort of cf push flow, but without the underpinnings of previous cloud foundry. So that's, if you haven't seen it check it out, works ongoing.

A

um It's still pretty new, so not by no means feature complete, but uh we're making a lot of progress and it's shaping up to be pretty cool so just to contextualize that that is what that is about.

A

Cool all right uh any other. Well, we can discuss that more if you want, or if there are any other topics. Anyone would like to bring up at the moment.

A

As always, we can use as much or as little of the time as we want. So understandably, if people are coming off of the shuffle from the holidays and all that we might not have a lot to discuss at the moment.

A

Cool sounds like it's uh a little quiet for the moment, so last chance to interject something before I wrap it up and say we'll see in two weeks: okay, cool. So thank you for the first time, attendees please come back.

A

Hopefully it's been worth your time uh and feel free to reach out and send any questions to myself or some of the other people via slack via direct message or the cf kate's dev black channel in the cloud foundry slack we'd love to hear from people make sure we're addressing the concerns that people have uh moving forward on. All of this and we'd really like to just have more more people to talk about to make sure everything is serving the needs. So uh again, once again, thank you.

A

Everyone for coming and uh we'll see you in about two weeks at the next meeting and we'll keep on moving so happy holidays. Everyone.