Add a meeting Rate this page

A

So.

B

Good morning or evening, wherever you may be,.

B

Hey jeffrey good.

B

Morning.

B

I.

C

Tell hey taylor good morning.

C

Everybody.

A

Give it just a another minute or two, and then we can kick things.

A

Off.

A

All right we're a couple minutes in. I think we can go ahead and kick things off taylor. Do you want to start with the um least privileged best practice.

B

Well, um we can, I was and surrendering a bit late, hoping he had joined here um all right. Does anyone have anything else, they'd like to add to the agenda before we get god.

B

If you haven't written it, do you want to verbalize it.

B

All right.

B

All.

B

Right.

B

Yeah, so I guess, if no one has anything else, then I'm good with starting jeffrey.

A

Okay, do you want to give a generic overview.

B

um Yeah, so this is, um I guess, just to start. This is related to the least privileged discussions that we've been having and least privilege. There could be principle, I guess the least privileged principle.

B

We could have several best practices that could come out of this and it seemed like no root in containers would be one.

B

That should be pretty reasonable to have agreement on and we can work on others, of course, but this would be a first and maybe the other thing about this was if we can get get a few best practices um in there um yeah into the repo, then it may be easier for other people to read so you're. Looking at, um we have a template and we have the only one.

B

There is not really a best practice, it's the process. So it's harder to look at that and, if you're the type of person that likes to start from examples.

B

So it's twofold, get this best practice in and have it as an example um anyways. So the it has all the sections, except for the user story, section um there's a lot of other content, so we're pretty close to writing out an actual user story. We'll probably link that to a new pr for that. But it has all the other sections, including a pretty pretty extensive reference section for going out to what other people talked about on this one.

B

um But yeah the the general idea would be not having any processes and in a container that are running as root so that they can.

B

They would, if anything, goes wrong, they're less likely to cause damage primarily to themselves, since there is some isolation being in a container and potentially, if there's any type of shared resources like containers, multiple containers in a pod, and there could be some type of damage if there's not isolation between those but that's the main idea and and then, when you're thinking about running a process, that's non-rude and what you're having to do as far as dropping privileges, then it it just moves you towards that whole mindset of running with the the least capabilities necessary to get the job done.

B

Some environments sc like seo linux based environments requiring dropping root privileges. So if, if you're already building your application to not require root, then you should be good to go in those type of environments and.

B

Yep, that would that kind of covers it. um We have the proposal section talk about when you're building a container and how that's related and what what you can do.

B

Some of the trade-offs, I guess, would be um the first process um by default- may be running as roots, so you have to think a little bit more. I guess it's a little bit more work up front. There may be upstream images that didn't think about setting the user, the uid and gid so that they're not root, which means, if those are your base configurations, you would have to take that into account. If you're building on a existing upstream image.

B

And then do modifications in your own docker file etc, and most of it's just around the I guess the extra work required and does a process expect things to be root owned in the file system like wherever it's accessing and making sure directories and stuff are owned by the user that you create so.

B

Let's see- and this would be uh workload context if and I'm talking, while you're showing your screen jeffrey, would it be better if I shed my screen while I'm talking to the.

A

Points.

B

All right, let me.

A

Do that, let us know what you want us to like jump into.

B

Oh yeah totally, and if you want to jump in, I guess the last part was just the work look. I can't share my screen unless you stop there, we go cool um right, so this is just looking on the diff display different and there's all the references, different places, um workload contacts, so this would be everywhere, is by default and pretty straightforward on a test plan, but there's a split between doing static analysis and and then run time analysis for um stuff like did they set user.

B

um The run commands allow you to express the user and other things like that. So there's things you can look at before the cnf starts running and then you can do various things with the runtime analysis.

B

um Volco has some stuff cncf project and there's other projects out there. That can try to look at the environment, see if any containers are running with root, um yeah and.

B

So I guess that's it folks have questions. I don't think there's I guess there has been some comments.

B

I guess before going through those I could.

A

I apologize.

B

When I looked.

A

Through my browsers this morning, I realized I never actually submitted my review so.

B

Oh all, right, if it's in draft you can hit cement.

C

I didn't write this as a comment, but maybe uh we'll just phrase it now. Another issue I thought about is uh it's quite rare, but there are uh pods that use system d, various reasons to do it. It's not so simple to set up, but it you can definitely set it up. um In that case, you, you might be running system services that are root.

C

um So it's not. You know, you know your main entry point might not be root, but there might be yes, there might be things running in root anyway, um and I can think of other things, uh uh cron jobs. You know it could also be through systemd. It doesn't have to be systemd right, it could be any kind of uh system service, um but given.

D

Even in that case, do you need the root user, or do you need relish permissions on that kind of process.

C

It could be either systemd can run uh uh user jobs, um but usually the reasons you want. It is probably because you need some sort of specific system service that is, that is root.

E

Yeah that that's a good call out as well root does not necessarily mean privileges. You can. You can have root without without privileges or you can have privileges without uh without root, so um we we probably want to make sure that we have guidance for for both uh for both sides.

F

Yeah, but that might just be that you're not compliant with this best practice. You've always got that option, um but for things like that, why do you need to be rude.

C

Well, I they only mention it. I don't know there might be a million reasons and you can always find another reason. I'm only mentioning this. We talked about docker files and you know, if that's the kind of test methodology that looks specifically at entry points and.

E

Yeah.

C

When you're talking about companies.

E

When you're talking about init systems on occasions- and I don't know how systemd is implemented here, but uh many init systems make the assumption that they're pid um that they're the lowest bid and if they're not the lowest pid, then they'll fail at doing what they want to do by by design. So it may not be. uh It may not be an issue in systemd, but there are net systems where uh your your pit matters.

F

Yeah but that's fine, your head would still be zero one whatever rather.

C

Right, my whole point here is just thinking about background services, as well as as just the entry point.

F

Yeah, I I I see that, um but you know a background service doesn't have to run as root is my point: if systemd for whatever reason requires being root, then you could fix systemd to be compliant rather than changing the user story, because because that would be the tail whacking, the dog.

C

Exactly no, my point is that maybe in the best practice we can add wording about um as well as background services, including systemd. Something like that. um Just to make sure that that it's covered as well yeah and just.

F

To remind people to double check your thinking.

E

And add another thing: these are guidelines, so people can escape them if they, if they need to.

A

I was gonna say so one of the things we should consider capturing right is: um we should limit like one best practice per input here right. um I think that there's a bunch of best practices that could come out of this. If we, you know, agree and move forward, that running is root. When you don't need to as a best practice, then we should cap this one to that.

A

um I do think that, like when we do these live discussions, it's a good chance to talk about um what other best practices would potentially fit to a user story or a use case. So that way you kind of build a portfolio against it, because um we talked about um you know getting like containers from vendors. I can tell you like one of the challenges I deal with, and this ian right here is the whole black box. I'm just going to give you something that works versus you know. I want to rip it apart.

A

What, if you hand me a container that is defaulting to root, and I come in and say the cncf says the best practice is not to run in root.

A

If I go in and modify the image- or I add additional layers, you'll tell me I'm outside of my service contract and that you know I'm breaking your stuff, um not you specifically, I'm just talking about in general, like you had this off so like um we've talked about like the clean, handoffs and stuff like that before, and I think this is kind of like one of those good first case.

A

Examples of um I don't want to run stuff and root and give you access to these types of things I mean I have you know a big multi-tenant environment. What if someone comes in starts doing things they shouldn't et cetera right so like what does it look like when you know I get something from a third party that defaults to root yeah.

F

So the there's two parts to that one is this best practices is audience. Is the cnf developer more than it is anybody else? You might care, you might say, follow the best practices when, during your cnf development, um but the cnf developer is the one that should care about this because ultimately running as roots, give or take the fact that isolation between users is not quite what it could be in kubernetes. But ultimately, the the use of root in a container is more about your cnf.

F

If your cnf breaks or if there's a security, intrusion or or whatever, not going completely ballistic, but it's still contained even with root privileges, it's still contained um because it's only container root, it doesn't get you out of the container, um but we did say at the bottom of this.

F

This is how you can test compliance if the root, if the first user it starts with, is not root and there are no setsid um files in the file system, then nothing is ever going to be able to get to root for one uh and the other one is we said well, there are monitoring systems and I think we gave a couple of examples which double check to make sure there aren't any local root processes running as well.

F

So you have it's not your job to change it. It's your job to say that I gave you a list of instructions.

F

um You know a set of acceptance, tests and you're, not passing them, um and so you know that is a different thing from I'm going to break my um support contract by you know, making changes to the software instead, you're saying you haven't met your acceptance test and the deliverable is deliverable is not acceptable. I'm not paying you which gives you the leverage you're looking for.

A

Yeah, I don't think it's quite that clean in the real world, because product people like to come up with deadlines, and you know things need to go to market and all this um I think in an ideal world. That's how it would work um and, like you said this being for developers like we've talked about this in the past right, like people will probably look at these repos and bake some of this stuff into an rfp right so like.

A

um Ideally, you would solve this as part of like an onboarding process, um but yeah. It doesn't.

F

Have that way, I think your onboarding process should not say if I find rooty sort of signs in your containers, I will reverse them. Your onboarding process should say I will detect these things and flagging on compliance. um You you aren't. There is no winner.

F

If you, if I supply you a when you're wanting b right, there's no way for you to get b out of a I either have to supply b or you have to modify it, and neither of those things you're saying is in the real world going to be anything anyone's going to be happy about absolutely. But um believers are there.

A

Yeah and in the uh I'm just wondering that this negotiation is just going to be tricky right, because this is going to come down to the system operator, telling the software developer, how to develop, and then you're going to have someone who comes and I'm just playing devil's advocate for a second, because I do. I think this was a good start. I think that this needs a lot more meat in it um because, like you're gonna have the person who's. Like listen.

A

Mr telco, don't tell me how to write my software because they're gonna come up with examples like pal just gave of you know. I've got this or that running, and I have to have it because of this and so yeah. I'm.

F

Just serious, that's a slightly different thing and I think something we need to write up at some point as well, which is um for anything like this, where you've got best practices and again I'm talking about when I used to work in well safety, critical systems, you are allowed to basically deviate from the standard as long as you write it down and the receiving side accepts what you've written.

F

So um we need to at some point, come up with how you document what you are compliant with in our best practice baselines, and if you are not compliant, you write down what you're not compliant with, and you know, should you so choose why you are not compliant because you're making an argument that the receiver should accept what you've given them, regardless the fact that you're not compliant because you know, because presumably it's no worse than it would otherwise be. I mean we had ridiculous things like pretty much, don't use pointers in c.

F

You can imagine how well that goes down. um So um there were non-compliances, we used to have to write in our software and it would have to be judged on a case-by-case basis by whoever we were selling that software too.

F

So.

A

On this point, though, and the point to my rambolism, if you go to the goal section um taylor, that's a tie. Yeah there we go. um I would.

A

I would make this a little bit more like flushed out and like succinctly just clearly I mean I feel like the second bullet's, pretty um pretty clear-cut, but like the first one doesn't really read like a goal, um so I would just call out like distinctly. These are the goals we're trying to achieve with these best practices? Then, if you go down to the test plan- um and this gets to your exact point in.

B

This is when.

A

We talk.

B

About when you're saying the goals like we may the summary pieces, the motivation goals, there's a lot of overlap between those you feel like yeah,.

A

But it all kind of like reads weird like I I don't know. I put some comments in like like motivation like it does both the benefit like it's two succinct sections but lynn like you're kind of like just inferring from the summary and the motivation which, depending on how you attack this, it just reads weird. So um all right. I would like.

B

Each section let's look at did you actually put the comment in mm-hmm.

A

And I'll give you an ian some more direct feedback. I read this over the weekend and, like I said, I forgot to hit submit, hence the uh 16 minutes ago thing but um and then like just real quick. I want to stay on like this original point, um so, okay clearly very clearly defining the goals.

A

So that way, someone knows what this best practice is striving to achieve, and then in the test plan, um and once again, this is one of those things where like when I first made my comment like if you actually look into static and runtime analysis, it gets a little like you're kind of doing some inference from like some things but, like I think, instead of being like too generic like for the actual test plan, I would like actually write out like some expectations and then I put in a comment.

A

um We've established this group isn't specifically about writing code, um but there is this cnf test suite. I think um like if we put like test plans together that, like validate that a best practice has been achieved or whatever hey this give somebody to like grade themselves against to ian's point. So then, if they say we're just not going to do this, they can point to exactly where they're making their compromises and then, additionally, if people did want to get more um on the code contribution side, they theoretically could automate some of the test plan.

A

And then you know contribute that back to the cnf test suite. So it gives our group a way to tie into some of the other groups and for the people who want to write some code. But um I think if we keep the test plan too generic then like the best practices, like did you put somewhere down in the bottom two about like evaluating cns this, and that I mean.

F

I'm confused here, because that test plan is pretty specific. It tells you exactly what you look for.

A

um I.

F

Mean.

A

I think maybe we just have different definitions of the test plan like I I get that tells me what I'm looking for it doesn't give layout a plan of what I'm testing some of that is in the static and runtime analysis, like I said, there's some inheritance between the um different like sub sections, but well, I would write like that's what I want to hear. What would you write?

A

I would write like you know, expected inputs and outputs, and this is what we're expecting right like and some of that like see user and run commands. um Some of that, like I said, is in the static analysis, but, like I mean a test plan to me infers that there is a plan that you're executing against and then that would have predefined inputs and outputs to validate whether or not you've got the results.

F

The test plan is effectively.

B

I think maybe the name of this section is um not good by saying test plan. If, if we take like the definitions of that people are going to use that are actually writing tests, it probably has a more specific thing, which I think is what you're saying um jeffrey.

B

So maybe the whole section is um just named wrong versus we're going much higher level like a yeah.

C

Business level.

B

Expectation.

C

I I agree with that. I'll add that um I I read this originally as this is. This is not a best practice. This is a principle right. We we intend to derive best practices from this, so talking about test plans here, a little bit jump the gun for me, because a best practice.

B

In my.

C

The tone is different: it's if you want to do this, then you should probably do this and here we're we're taking this principle and saying well, this is the rule right now and there's a combined sweep. This is maybe.

F

A.

C

Part.

F

Here I I'm a little confused by what you mean. By that I mean the best practice is literally don't do this thing and the test plan says I will look to make sure you are not doing this thing and the test plan is written in such a way that it is testable by you know. Code um I mean I wouldn't care if it was testable, I wouldn't be happy, but I it would at least be acceptable if it was had to be tested by a human being, but it is testable by code.

F

In this instance, um the test plan talks in generic terms because it isn't the test. It's a plan. um You know, I'm not writing you code to do the test and embedding it in the document. I'm telling you how the code goes about what it does and what it's looking for.

F

So when you say it's principle, not a best practice, the principle is least privilege which isn't written in here. The best practices do not run anything as rude, um which is a yes, no answer. Are you running things as root? Yes, no. Can I test whether you're running things as you root? Yes, no. If these tests pass, you are not running things as root. There is no way you can get to root, so I think I'm arguing with both of you, but I I mean starting with tao.

F

Why is this a principle and not a best practice.

C

I well if it is a best practice, I'm a little worried then too, with the tone. um I didn't read it that way. Why? Because sometimes you do need to use root, and then the question is okay. What guidance can we give to people, for example, uh pods, but I'll give you one example right: a pod does not need to have one kind of container. It could have multiple containers, but the way kubernetes works privileges are granted per pod and not per container, so one best practice could be.

C

If you do have a container that needs a root. You want to isolate it, maybe into a pod, rather than mix it with uh uh with other containers that do not need root right so to to reduce the attack surface. If we will, if you want to talk security, um if you need to use system d, then use system d with a user rather than root right. There are all these things that you can. Why do I need roots in a container?

C

I don't know there is a zillion reasons I can think about in terms of of uh specifically network functions interactions with the host the operating system. At some point, you'll probably need to do that somewhere and the idea is to isolate it. So the principle is least right: it doesn't mean zero uh somewhere there there will need to be some sort of privilege. So then the questions are: do you want it to be even a workload on kubernetes?

C

Should it be something like a cni plug-in that runs on the host rather than a workload, a containerized workload that a lot of questions here that I think are very interesting and that we could provide guidance?

C

uh The idea of jumping to compliance about containers seems to me uh going to some very specific use case here to me to me. It looks like a step too far. We haven't even established compliance and what that could mean and why a compliant application has to have all containers avoid the use of route 100 um and.

B

Hey- and maybe um this word right here- we don't have enough context- I think what you remaining when we put this in inside a compliant application. I think that's compliant to this best practice. Correct.

E

Compliant.

B

To all things yeah, so the suggestion then- and maybe we could write it to be more explicit like that. So then we're saying if this is a best practice, then um it just because you don't follow this best practice doesn't mean that the entire cnf or application is not cloud native or anything else. We're saying try to avoid using root, not when you can't so, if you can have a best practice that you decide is doesn't work for you and that's fine.

B

Just saying.

C

In general,.

B

In.

C

General we're saying try to avoid.

B

Yeah.

C

And then.

B

Help people like.

C

Well, how do you avoid to use root? I think that's what I I look for guidance here that I I'm not.

B

Looking for somebody.

C

To tell me what not to do I'm trying? Well I, this is how I work. You know I need root at some places. Well,.

A

If not, what can you.

C

Suggest I.

A

Disagree a little bit now. I I want to disagree on that point like I think, we're supposed to be probably getting guidance. I think taylor hit the nail on the head, though, and I don't necessarily think this needs to stop like a pr from being accepted, but like I think that there is not enough context, taylor used.

A

The right word is like you you need to like, like I said, I think the goals need to be very very clearly and succinctly stated independently, like you get this this and this, this is what we're you know cheap or seeking out to achieve with this best practice I mean I don't know like I don't I don't.

A

I slightly disagree with you, tal and like um I do think we should be somewhat prescriptive because you can just choose not to follow this best practice and be like these are my reasons why I just don't think, there's enough context in this for someone to cleanly articulate their reasons. Why, um like what are.

F

The trade-offs.

F

I intended for a second and see what you read in, because it might not have come across in the document. The thing that container roots lets you do literally the only thing it lets you do, because most of the things that root can do really aren't allowed in containers. Is it lets you change it lets you read right and change permissions any file in the file system, um which is probably not what you want.

F

um You can't stop anything. That's got root from doing that, so every file system protection you put in place is thrown out the window.

F

And so, if you wish your file system protections to mean anything, then you should not run anything as root.

C

But what? If? What? If you do want to change a file system installed file for it, for whatever.

A

You just don't use this best practice.

F

Now you use it, you give it a bonus. You give ownership of it to a different user that can change the file.

E

So.

F

um I think.

E

I think part of the way to look at it is. I think there is a context issue here. What I would recommend doing is separating this up into first from a test perspective.

E

We we need to be able to say that this thing is an audit mode versus this thing is enforce mode and get, and that gives the uh the uh various groups the capability to pick and choose the things, the best practices or future compliance things that they exist, the ability to set their their policies and baselines. So they can then uh discover and and optionally enforce things that they care about.

E

The the other thing as well. Is uh you look at it from a vendor and consumer perspective? The vendor will say I I have verified or ran some verification program that that has given me information about whether this thing meets certain requirements and the testbed can can help there. What it doesn't do is it doesn't say whether this thing is fit for purpose by the consumer, whether it's valid, whether it's, whether it's a validated system, that's something that the consumer, in this case uh jeffrey and his team, would have to work out.

E

Is this thing fit for purpose, and this is where the we we want to have some of the best guidance or best practices to say like? uh Is it good for purpose? Is it fit for a purpose from a security perspective, just use that as an example, in which case you could say we want. We want no route. We want to have privilege escalation. Disabled there's, actually a privilege escalation. We did within kubernetes that doesn't allow you to that, turns off the suet or ignores the sewage the sewage bit.

E

We want to drop all capabilities, except for the ones that are absolutely minimum, that you've compartmentalized and some of it is through enter the mixture of the verification and validation combined. Ideally, you should get to somewhere. That is, uh that is uh cons consumable, but at the same time you provide that information out. So it ends up becoming a conversation between the two and not uh not an enforcement, which I I don't think we'll have the ability to do from here.

A

Right, I I want to point out one thing too: I I don't think that it's a zero-sum game, like I think both ian and cal, can have what they want. I think ian, if you do a better job of describing in this document, what you just described in words, then we say: okay, this is what we're trying to achieve with this best practice.

A

Then, if tal has an exception, we shouldn't write the best practices with the mindset of all these exceptions, but we should just tell you this. You say like look. This is what this best practice is seeking out, but dot dot dot. I have to do this. Therefore, I'm gonna run this container as root, and then you say: okay, I accept that risk, because pal needs to accomplish x. You know, but like we shouldn't water down the best practice in my opinion, tell because we know that the exceptions are coming.

A

We should just make sure that the best practices clearly state what they're trying to do so that way, when you do want to make the exception, it's easier for you to articulate that.

C

Yeah, I I don't disagree with that. I think my point is, uh as others upset you, that there's there's room for more context here and more guidance. I would say and more uh I think you know jeffrey. You said it reads a little bit weird. I think the tone is just uh the word compliance I find a little bit scary right. I I could easily see a telco taking this and saying. Okay, you, you need to do this, there's a test suite and.

B

It does it doesn't really we can re, we, we don't have to do uh compliance as far as these words. It's not.

E

It's not the.

F

Intended.

B

Thing for uh what ian was saying.

F

It is literally, it is literally compliant to this best practice and right. The word compliant.

B

Is.

F

A perfectly acceptable one to use there, but I think you're saying that it might come with connotations. We don't want to go with tal. You said several times without listing them. There are reasons why you might want to use root, and I think what we're saying here is: if there are reasons why you might want to root. If we can list those out, or at least as many of them as we can think of out, then we.

B

Can.

F

Give people reasons either. You know you can explain to both parties well. This is a reason why you would want a deviation, so you should write your deviation up and explain these words dear application, consumer.

F

A deviation of this nature is normal and expected you might want to just give them the green light on that or, alternatively, have you thought of this alternative way of doing it that doesn't require root. That would also be another thing you could do there. There are um your example of systemd. To take an example is basically saying there is software in the world that people want to use which shouldn't need root but insists upon it anyway. Perhaps so, we've got to non-compliances are perfectly fine.

F

They are an expected part of this process. Frankly, nothing is going to be 100 compliant at least to begin with. um So we just need to help people through the process of using what we write, not necessarily changing this, because a best practice that says well, you might not care to follow the best practice, is basically not best practice, whereas a best practice that says this is the platonic ideal of a container in an application.

F

Is you know fine, you know it doesn't always come up to. It doesn't always work in the face of reality, but it is nevertheless the ideal that we should all strive towards.

E

The framework that is often used in this in this particular path when you start looking at overall governance, is you end up with policy and standards at the top policies? Are things like all? Data at rest must be encrypted uh standard would be like we use aes and then at the lower end, you end up with procedures and guidance procedures. Are we use bitlocker to encrypt windows systems with aes in this way versus guidelines, which is like? Don't leave your laptop in the car? The difference between the two is that procedures are always mandatory.

E

Guidelines are optional, but very tend to be very good advice in this scenario, we're focusing primarily on guidelines, but it is possible that in the operational side, people may elevate some of these things into into procedures, and so we want to make sure that they're that they are testable when they can be which gives the uh which gives the various groups, both on the vendor and consumer side, the ability to to audit and enforce when they want to. But ultimately those knobs become become tunable, and we focus only on guidance.

E

We don't tell people when is when, should you move up to procedures, because that's that's something that the internal organizations need to work out based upon their their policies and and standards.

C

Everything, you said is perfectly reasonable. You know just add. um Look the user story here is tbd right. We we didn't really start with the user story, so we don't. We, we kind of jumped jumped a little bit ahead here. I I think that the document as it stands right now just feels a little lopsided to me. It kind of jumped to the end of okay, no root and there's there's a big story along the way, starting from the user stories stories right and going towards.

C

Well, you know the user thinks they need root, they probably don't um and if they think they do, they don't realize what the problems could be and and requiring root. So we kind of jumped right to to the end rather than than than building something along the way. It might be obvious. You know to to all of us reading this, but I I'm not sure it'll be 100 obvious to people say well. Why not?

C

Why not? This was never intended to be.

F

Released without it, this was never intended to be released without the user story to back it up.

B

But it's.

F

Marked as a work.

B

In progress yeah, I I couldn't for some reason on this repo. I couldn't make this literally a draft pull request, or I would have done that so there's definitely no suggestion to accept it. We're wanting feedback and and the user story would go in there too. I do uh ian before you respond on anything.

B

I do want to point out that this section here in the trade-offs caveats notes is specifically for adding things like here are why someone would be doing something else and an exception, and then you can talk about how to deal with that. I mean that's what this section is, and this.

E

Right here.

B

Is very similar to what you're saying with systemd and other stuff, so you have a container image that already uses root and already has set id binaries. So that's just an example. We could you could do a comment with the suggest edit to add some other examples.

B

If you want to a section, go ahead.

F

I I I would suggest that, if we're going to come up with advice on how to consume this, like, for instance, those things where again tells saying you know, I've got a laundry list of reasons why I might want to use root that we don't. We try not to build it into the best practice. We try and keep the best practice short and sweet. We come up with a guidance note that goes along with the best practice to to kind of say. Well, you know these are things where you will probably find deviations.

B

I agree with that. I think this is one example, but we don't want to listen and we didn't. You didn't go into like extensive here's how to how to handle that. I don't think we should. I. I agree that we shouldn't have all the examples of the all the exceptions listed and how to manage them as well as.

A

We don't want to manage.

B

um

A

We want to change this.

B

Sorry go ahead, jeffrey.

A

No, I thought like that was really weird you, your thing cut out. I thought you would stop talking didn't mean to stomp all over you there. That was weird stuff with my headset. I think I just said we don't want to write things to exceptions.

A

We want to write them to the 90 right and I think one other thing that would help when we talk about this context and things that we should add in is like as you're reading these you know that there's going to be complimentary, best practices that fit underneath one of these principles right so, if least privilege is our principle. No root is one best practice, another best practice. You know, and we should like capture this and um you know keep tabs on it is, you know, create users with the appropriate amount of permissions right.

A

This gets into ian's. Point of you know: are there going to be times when we might need to use your root sure, but the best practice is don't run root. Another best practice is to create the correct user, with the appropriate permissions to execute the task as needed right, and so I think when we get into some of these, like you know, what-if discussions too, if we just track what other best practices would complement this one and how you kind of build like the suite of best practices underneath the least privileges umbrella.

A

Some of that context is also handled and then to your point, taylor, we don't need to list the 5000 exceptions of when we're going to violate this.

C

Well, you know, I'm I'm really interested in those guidances more than than this document. I have to say I get questions all the time. For example, people wanting to run ssh sshd right in a in a container for various reasons. If it's accepting netconf, if it's something else now, how do you do that with it without access to it? How do you update certificates? How do you do other things? Where do you put it in the build process?

C

um Nobody wants to run root. I think I think this any decent programmer reads this, and this is very obvious right. Of course, we don't want to run root, uh but what do you want us to do? Instead? What do you suggest? What is the ecosystem? What is an alternative to sshd that can run in a more cloud-native environment without these requirements?

C

um That, to me, is the more interesting part than this, but but but but fine, you know we have to start somewhere I'm this is. I have no problem with it with the the principle itself.

C

Let's go.

B

That's tal, I I sorry victor. um I love the idea of recommendations on how to implement something so, whether that's dealing with exceptions or people that are saying, oh, I I lack the best practice now. How do I do it and with the software I have, because it's not set up for that, so helping people to actually implement sounds great, and I think that could be a new section that we could have within the cnf working group. Where we talk about that, here's the best practice, and now we start.

B

Maybe this is a folder for instance, so this would be one way to look at it um just bring this up, so we don't have folders yet, but under use cases some of these we have folders.

B

So if we had a best practice for not using root within that folder, maybe we have here's a bunch of other documents that talk about what about images that use systemd? What do you do for that? And then we could talk all about that and keep it separate from the main best practice document, but allow us to add, as many as we want for real situations.

C

That makes sense to me yeah and I'll just remind myself and others here that we specifically picked this one, because it's a low-hanging fruit, that's very obvious, so yeah and in a sense this is a very trivial best practice right, but even here we see that there's uh there's some subtlety in terms of um um actually no. This is non-subtle. I think that's what's interesting about it. This is not a non-subtle best practice right, just don't use rube.

C

um It's quite blunt.

F

It's deliberately quite blunt um and and again your shopping list of reasons. Why actually well? I might want to use route anyway.

F

The ones that I would categorize as pragmatic are ones where I'm using something like system d, which thinks it's going to be root because it's been written in a circumstance where it'll always be root and it's going to be difficult to run otherwise, and I don't spend intent to spend all the time changing it to understand that it isn't going to be rooted in all circumstances.

D

Are.

F

There use cases that fall on the other side of the spectrum, where root is absolutely essential to what I'm doing, and nothing else will do, because those would be the interesting ones.

E

The thing I like about the guidance here specifically is that I can have this thing as a test and I'm not saying you don't do it, but in an audit mode.

E

If, when I, when I'm in the process of doing an audit, uh all right, sorry, two different audits, uh then I can say well here are the things that use root, that we need to spend extra time focusing on because they do dangerous things, and it allows me to to have teams focus on those explicit things, because I know that they're that they're high risk items- so I think part of it is being very blunt here- is good.

E

Having something that's testable is good and again how you, how you adjust the knobs matters, matters a lot, and I think part of what we need to do is make sure that we're very clear that we're developing guidance and that the guidance can be consumed in these other ways. Other than just enforcement on.

C

I, I might add you know, I said this is a very blunt uh uh best practice. There is a tiny little subtlety that I want to point out, and that is that um there's been an evolution from the early days of docker to truly what's cloud native in kubernetes right, there's something very cloud native about this, because early on docker was exactly about the point of isolation.

C

Sure use root, do whatever you want inside the container, because it's completely isolated, it's not the real root. It's not the host group. All you're doing is changing stuff inside the container. uh We're thinking about this differently. We've evolved our thinking over time right because we're thinking about these uh different pods different containers working together to do something and the kind of reliability that we want. There is not you know, do whatever you want inside the container.

C

It's remember that you're playing as part of a bigger system here, um so so you're thinking about attack surfaces as being not isolated in one place, but you're saying well. This is one dot and inside a larger topology that I need to think of. So if I have everybody using root, I'm I'm really it's very hard to tame these cats.

C

um So so there's something a little bit surprising here for some people who might be new to kubernetes- and um you know not not 100 obvious to to every developer. I guess.

E

That's an excellent point and we ran into that same problem when docker was new, so in 2013 a large part of the messaging that we did was uh look at 12-factor apps. We know that they're not perfect. They don't align to everything. But if you understand the guidance there then it'll help you achieve what you want within docker, and I think that they're similar that this this can help in that same path.

E

Where we're going to get people who have never used kubernetes, they don't know what a pod is and we're asking them to go, build cns, so we're going to run into the same problem. Why do I not need? Why do I not need root? Why do I not need privileges? What why why do? I need immutable infrastructure and providing that that guidance as to why it's important and how it all fits together is crucial towards helping them be successful.

C

Yeah and it's it's actually a huge developer problem, a lot of people work with docker, and then they think the next step is then putting it on the cloud. But the whole idea of cloud native right. We we're what we're trying to say here is you have to think cloud natively from the very beginning from your architecture, but you don't write a single line of code right of a network function before you understand that this is going to be a cloud native network function.

D

Well, the other thing that I would like to discuss is well when I was reading this particular pr, I noticed is that poker has the username space remap feature that you have to enable in the demon to especially there is two to occur to to to modify the the the user use when a new container is user uh uses, um but I noticed that this feature is not supported like like you are not so.

D

At least I tried to to to run a cubespray cluster using that feature and that didn't work, because um api services requires um that that specific mapping, so I don't know if we should also- I don't know if, if that, once that this feature this uh username space remap feature is supported in kubernetes, it's going to make sense to still.

D

Enforcing users to not use no root containers or is going to be an extra addition, um concealer or something like that.

C

That's a very good point. That's another one of those you know when I said there are so many reasons why you might want to use root. You know I I don't know even where to start here's one potentially right so again, there are other things you can do. Instead, you know, there's there's never only one way to do something.

A

I think the part- that's I'm you keep coming to this point and the part that I'm a little hung up with is even if there are instances where we would want to use root. Does that change the fact that it's still a best practice to avoid using root.

C

No, no, no, I'm not disagreeing at all with this best practice. I'm I'm trying to make this document helpful, uh so I I think, uh but what we can add, we can put it as you know, supplements to it. You know it's if the.

B

Point of this particular document.

C

Is just to state the principle, uh I'm happy with that. I think it kind of bleeds into other thing when it talks about test plans. I think that's beyond just stating the principle: that's how to enforce it. That's a little bit different, but um I I think I made my point so whether people agree with me or not, I I have nothing more to add all.

B

I would say is edit for the test plan to remove compliant that the idea is: do we all best practices that anyone puts forward? We would like to be able to somehow test it. It doesn't.

E

Mean that.

B

Anything about enforcement, frederick keeps saying I've said that, are you a difference between enforcement and just notifying whether expectation of the test is one way or another? That's all we're putting forward when you have a best practice, can you implement it? Is it possible at all? Yes, it's possible to use, root or not use root.

B

Can you test that, whether using root or not, those are the the main things that we want for any best practice bit forward.

C

Sure yeah, I might have a history here with with the words and I'm sure others do too and cntt and other organizations that the word compliance is a very very big word. I mean we have whole teams just based around compliance and and software etc. It's it's a.

E

Difficult.

B

Word.

E

It's also an overloaded.

B

Word because.

E

I don't have about this right here. Yeah.

B

An application which follows this best practice will not have any containers with processes running as right. Remove.

C

Compliance.

B

Completely.

C

That's fine. I mean it reads a little bit total logical, but again this is a very blunt uh best practice. It's very clear what it says: it's there in the title to an extent, so so yeah yeah. So tell me in that sentence that you're.

D

Considering side cards as well.

C

Oh, absolutely I mean side. Car is kind of it's just another pot in the container they're. Also the issue of innate containers. There are various ways you can put containers inside pod, a pod. The thing is that the pod concept itself is very interesting right. It's a it's. The pod creates a context that is shared by all the containers that are running in there, but the containers are still containers they're still.

E

Isolated.

C

This is a thing by.

E

The way a lot of people right side, cars end up with the same security as the uh as the main container. uh So there's no difference. You give root to your side car. Your main application has reached.

C

Yeah I'll give I'll give a very popular example, which you know when people hear sidecar, they always think of istio right. That's the the one uh operator and product that uses probably sidecars. More than anything, the sidecar is changing the ip tables for the pod. The ip tables are used by all containers in the pod, so the sidecar is able here to use privileges right to to actually redirect all the network uh traffic coming inside and outside of the pod.

C

It's a very powerful uh thing to do, and that is all based on privileges right, you're, giving your sidecar the privileges to do that, because you trust you know what it's going to do and the features uh is one that you want so yeah. My point is that there's there's a much bigger story here than than just uh uh this best practice as it is, but it's it's still. You know I agree with the best practice right.

C

You do want to not use root when you don't have to, and if you think you have to you, probably don't so, there's a narrative, it's, but but I'm okay with making it you know short and sweet. Is the word that people seem to like here? Let's make its extent and then add supplemental documents that um that that dive, deeper.

E

Yeah, if you want to hear something really scary, all pods by default, get the net raw capability, which means that they can read and write things directly onto the uh onto the network uh and they need this for pinged, because icmp responds responding to icmp requires the network capability, so um yeah in. In short, this is this is uh why layering and other things like setcomp or other policy engines like falco and similar, become very, uh become very important in in that aspect.

E

So uh there's there's other topics we can jump into there as well, but uh we want to keep this. We want to keep this one simple.

C

Right just a quick point: sidecars actually.

B

We're at the top of the hour, um so let's keep adding or hold it, either add right into the notes or the ticket or bring it next week to respect everyone's time.

B

Tal, please add some stuff into the pull request um and check out anything. That's there as well. Add some comments.

B

See you next week.

B

You.
youtube image
From YouTube: CNF WG Meeting 2021-07-26

Description

CNF WG Meeting 2021-07-26