GitLab Configure Stage, 7 Jul 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Configure tech discovery: Manifest projects outside of the Agent configuration project

Description

https://gitlab.com/gitlab-org/gitlab/-/issues/283885

A

B

All right, so this is the apac technical discovery for manifest projects outside of the agent configuration project. There was already a meeting earlier today for europe and north america and yeah I'm going to start summarizing some of those or I guess we're going to rediscuss all those points now.

B

So one thing um I guess actually um mikhail. You were part of this meeting here. That victor is mentioning the.

C

Thing about personal.

B

Life yeah, he said uh you met with emre farquhas.

C

B

About uh personal access to opinion, service accounts and all of that.

C

B

And the brief summary was so that I guess only tiger may not have been aware of this. One.

C

So I will summarize it for the recording anyway, so.

C

Yes, service accounts would be perfect much, but they are not scheduled. Work on them is not scheduled, and nobody knows when that will happen and uh it might take up to- or at least three milestones.

C

So basically, we are not waiting for them and uh alternatives that he suggested also don't work for us so like we have to roll our own solution. Basically database based most likely because because of groups.

A

And additionally, it's premium feature as well right and uh there is a requirement that you need to do something for core that cords. Okay,.

B

All right so in tiger you have the next point.

D

Yeah, so my idea was, since we can't use well since we're unable to use an external file. This is all on the assumption that um it's being group level, we can't use anything in a repo, and so we've got a fairly similar, similar process at the moment where we receive configuration from caz about ci access- and this is actually very similar- I was thinking we could extend this to work as a double opt-in mechanism for github's access.

D

It would work in mostly the same way when chaos would have to push some config to get their browse and we would populate a set of database records instead of access being allowed immediately. These would function as access requests.

D

That way, we can show them in a ui somewhere on project and group level. Someone can approve them and then, once they're approved, when the check is performed, whether a agent has access to a project. We can just look for the presence of an approved record here for the project or the group, a group above it, and this is simpler than uh ci access, because we don't have any of the performance problems that we had to kind of put in place. Restrictions for in ci access.

D

Because of my comment here, which is, we know the project and the agent ahead of time. So we don't have to do a big sweeping search for all the agents that are relevant to a project. So we kind of get around that problem, which is kind of why we have this issue in ci access today.

D

uh That's the summary of the point and um of the idea and there's a whole bunch of discussion under here that.

A

Yeah, that's uh I really like this idea. I think it's a very uh nice user experience um and then I was trying to understand all the concepts and whether we and how much we could reuse what we currently have.

A

So, if understood correctly, like I said as soon as someone at edits the agent config, this will dispatch like a record in a database which is like a access request and then, when someone approves the access request, I was thinking this could be like the same that we have nowadays. So it's just like it would add authoritization record to the database on the group- authorization for instance table and then it's all the same.

A

We just would need that tweak to also search for authorizations outside of the group hierarchy that we removed on the first attempt so bring that back and then everything it's kind of already in place, but yeah you've, you commented just below if I was asking, if this would be possible, yeah.

D

Yeah, so that would totally work for get ops um and the issue with ci access is the performance problem I mean for a small group, it absolutely would work, but we would have to test it out. um I'm sure, there's some groups out there with huge numbers of projects and the problem with this is they are every project. Is a potential agent configuration project? Obviously not a lot of them will be, but it doesn't really help with the search. So we can try, um but we might.

D

I think we might run into problems for very large groups, but it's probably still solvable. um So I don't think that should block us here.

A

And there's also a follow-up question that I didn't write if you allow me to to keep the discussion going here, uh because there is this like uh requirement where we expect that uh it works exactly like this. What to exclaim explain right now for projects that would be like under a certain route level name space, and then the agent can be configured to anyone under that root level.

A

Namespace like because that's uh like a company that has like a sas usage of gitlab, then they would have like the root name space, but for a self-managed they wouldn't have the the root level. I think, right to the heat, you could have like anyone giving access to anyone on different name spaces.

A

So would this be yet? uh We would have to work yet on something different. That's even more broad that, like checks for authentication for everyone, then.

D

Yeah, so this is where it got a bit unclear. Technically, it would still work, um but it feels wrong to have to be able to just link these things completely uh with it without some kind of other process in place um so yeah. I think the process would still be the same, but we would need another layer on top for determining if the group or determining the access between them, even though it's self-managed, we can't assume that um access will be implicit.

D

So I think there does need to be another layer um and tokens seem like a good, uh a good idea, but then I've just seen that they are not for free. So I'm still not sure what uh the solution there is.

A

Do you mean another layer is needed because we couldn't distinct of this specific behavior between gitlab.com and sas like the behavior should be the same, and therefore it uh yeah like why? Why would we need a second layer? That's right, I don't understand.

D

I I well, I think so, even if you so assuming self-managed, it doesn't necessarily imply that one company right or one set of users that should have access to everything, and I thought it would be odd if you had two top-level name spaces on self-managed and you could fill an authorization screen from one in one group from a completely different top level space with users that aren't common between them. They could be completely separate.

D

So I think the self-managed um doesn't necessarily imply same company, because there are things like uh you know: open source projects that use the gitlab for many different things um and you they still have uh open sign up um so yeah. I think it might need something else, so that mainly so we can't just have we don't get groups that get spammed with also authorization requests from groups that have no relation to whatsoever, but.

C

Isn't it the reason to we want to have authorization process, so you accept requests to mitigate that problem like and now we are talking about yet another way to block the problem like we already have one way. It's.

B

C

D

B

D

Oh, I was gonna say it would be, it would be frustrating as a group owner to just have constant requests coming in that you knew nothing about and were never planning on accepting, and you just had pages and pages of them that you had to sift through to use your own to accept your own requests. You.

C

Go and complain to each other if you are in the same company that some people in.

B

Another department.

C

Are harassing you, I mean it's it's a organizational problem. I don't think like it will be an often often you know problem, uh but on gitlab.com. I think that's a valid concern.

C

um So that's why I think victor is suggesting uh to have the.

C

To have them sectioned by the top level namespace. I think that makes sense.

A

But I also like, I think the query for ci will be even crazier if we allow for anyone even outside of the root level. Namespace right, the query is even more challenging because now it's suddenly everyone. So it's if you have some kind of different authorization, that's more like one-to-one thing. You know then uh yeah yeah, something that you can collect the list of authorizations for that agent if this is recorded somewhere for that project. If this is recorded.

D

Somewhere for ci access, it could get pretty wild.

A

D

When, when a project could, in theory, have we'd have to look at very every other project on the instance in the worst case,.

C

uh So this is like uh which which agents ci from this project can access right.

D

Yeah, so it's slightly separate uh slightly different. um We might end up needing to keep the distinction between them and have keep the restriction in ci access for now, which is the uh must be part of the hierarchy um but yeah. Well, I think it will for good ops. I don't think we have this problem.

A

Yeah, that said, I also can see that I remember that this was the specific case that, uh for that issue, that we have where the title is something like ci does not work outside of the project. That's exactly what they want yeah. They want two different level name spaces, giving access to each other.

C

And we need this, we need to fetch all all of that, like all the projects that access all the agents that are accessible from project to generate the config file that we inject into the job right, yes- and another thing is when.

C

Cass makes that same call to get the agents that are authorized for for a job talking is that is that correct.

C

Allow the agent's api call.

D

It's probably it's probably the same. Yes, I'm assuming so yeah.

D

But we can solve that separately.

D

It would be nice if the gitops solution works for both, but it.

B

D

B

I wanted to just come back a little bit to the cross group thing because I really do think there are uh self-managed instances that are really like sas.

B

So this probably should be a setting or something.

D

Maybe it's a group level opt out and if you toggle this flag, then your group cannot be cannot be configured. You'll never have um requests show, um but I can also see if the next feature request. On top of that will be. I want my group to opt out of every thing that I don't know about ahead of time and then we've kind of gone full circle.

B

One thing I will just realized when you were talking about it, I I have seen spam requests.

B

I've even received spam requests to some of my projects for uh member access, and they worry like for gitlab projects, even like some people are like hey, give me developer access to this thing. I've seen that too yeah yeah. So I'm wondering if there is a solution there, like, I feel like with users. We solve it by just banning them.

A

A um that, you can say, do not accept requests, uh access, requests for a group or project.

D

That's right: yeah users can request access as a there's. A setting is that.

C

D

Something similar to that.

C

Yeah, if we have a present precedent that we can use, then that's good.

A

I think the good thing is the about this is that the request access comes when we parse the file, so this makes it kind of simple to manage, because you just at this moment, you pass the file and you define, can you can you create an access request for this one or you can't because of something because of a setting or because it's other side of your outside of your scope.

C

Yeah, so maybe on on gitlab.com, this setting needs to be needs to default, to opt-out and on self-managed. This needs to default, to opt-in or the other way around, whatever enable disabled.

A

The idea that victor had was uh is this the same thing now, I'm thinking there is a bullet somewhere in this dock that we talk about, allowing everyone uh by default could be like a first iteration. Was this for you? Can you remember what to discuss.

B

Yeah yeah yeah, so this is something that victor was uh talking. He mentioned this in respect to my question about it was. It was basically the same thing I was thinking like. I was thinking about cross uh group requests and thinking like if you were a certain level, then you could auto like we would need to approve, because, because of where your request was coming from, it would be safe to auto, approve it.

B

But um in response to that point, victor said uh that he wanted core to not have approvals at all, so that somewhat actually negates the whole. Like you know, gnome kitty debian, all of those would be core and they would not have approvals at all like they would just auto, have auto accepted across group sharing.

C

Even on top level you mean, or is it only for nested child projects.

A

I think I think we're talking by about uh self-managed, I think, for home. We want uh yeah, then you and no actually for dot com. So if you dot com, you have the your company's hierarchy and we need to be strict about the company's hierarchy request. So when you try to request something, you should check, is it under your hierarchy or not? Otherwise, you failed the request. Before the request even is created, you fear the person and then, if you add some something that's inside of your company, then the access is granted.

A

Actually that I think that that's the idea that the access granted, so there is no option to deny it that that's what would be premium like saying, I'm I'm opting out or I don't want uh auto access accepting, but considering that you're inside of the same company so first for self managed.

A

uh So this would be like first iteration. I think that's what we thought so because it's uh easier to start and create less work in dealing with uh with settings, so self-manage would be also the same. Let's understand, but can we can it be the same if you, if we have this problem of not being the same company for self-managed, if you have more than one company self-managed as well, then the requirements.

B

I think if we keep the setting that allows you to deny requests entirely, then that might be an okay compromise for core.

B

Does that make sense.

C

So it's influx wise wide setting, uh which is basically enable gitlab.com mode on off and self-managed customers can just turn it on or off. Is that what you are suggesting.

B

Yeah except like for core, uh so I made a point bold there and I had an apac thing. So it's it's this point here.

B

So victor thanks, the the acceptor deny feature for when you share act like so when you request the git ups, access that, like on self manage it, should just uh no one on core self managed, so in a completely free self-managed. It should just be uh auto, accept maybe also in core um actually maybe also on free on github.com within uh uh single.

B

But it would be: oh yes, yeah! That's a good question! Yeah that wouldn't be able to work for private projects.

C

It shouldn't work for private project automatically.

C

Or public projects with private repositories, I know now.

B

Yeah, that's a that's a tricky one. Actually the project can be public uh and then different parts of it. You can make any part of it private, pretty much.

B

B

B

Yeah I mean the whole point of this is- is to handle like you're, requesting you're, requesting access to something that is private.

C

Or it's in another group, another hierarchy.

C

I mean if it is in another hierarchy, but it is public. It's already possible right today,.

B

Yeah because it's public forget for get ups anyway, yeah go.

C

Get ups yeah, okay,.

B

Or cia access- it's not possible so.

C

The whole point is to allow you know to access private reports and automatically allowing private repositories in core. Instead of managed is not an option or in cloud either. It's not an option.

C

So we can't make this feature premium, what it looks like, or maybe we just I'm missing something. What victor has in mind? I don't know.

A

I think we completely forgot about this. This is this morning about private projects.

C

Everything is up, and so.

A

Yeah who needs him? Why are we having this meeting again.

C

Everybody is kind, and you know, have have good good intentions, so why not give everybody maintain their access.

B

It's it's difficult when we have such a long discussion that we end up forgetting the original topic.

B

B

I think I think we can move on from this point. Then.

D

For the database.

B

So I think your file based error I wanted to get back to because we were talking about the query thing, um and that was a topic that was uh kind of deferred until this meeting, which is uh the the table structure like uh so, should there be one table with multiple columns, uh so one for request and one for uh acceptance was a one for request and one for grant or one or should that be two tables one for a request and one for grants.

B

And the edge case that that we should consider is around when things are when accepting and and removing access are happening around the same time that we don't want to accidentally.

B

Lose the revocal revocation of of access. Does that make sense so when an agent owner says like I had previously had like there's access currently granted and I'm revoking it, but at the same time the like a project owner that was being given access accepts it so that, like those two actions happen at the same time, we want to make sure that um access is revoked, no matter what.

B

So we don't accidentally write.

C

If it's a single table, then it should probably be a single row. If it's two tables we just have a foreign key and the cascade delete, and am I am, I not understanding, maybe.

B

No, I I think I think it makes sense like the point was the point that um nico made was. It was referring to a specific thing that tiger wrote about deleting so if config is removed for git, the records are deleted, access is removed.

B

So, let's go. Let me highlight this point.

B

This is nico's questions. Question is there? uh Is there a possible race condition when uh deletion happens.

B

Does the question make sense.

D

Yeah, um I think so, for what I think this do we have this problem with ci access anyway,.

B

Well, no, because there's no acceptance there, uh there is a delay in in re-indexing.

D

Yeah but the if, if the if a commit, has gone into the configuration project removing access, but um if that happens at the same time that we're generating, I suppose, would generate a cube config that can't be used right.

D

C

Which is, I.

D

C

Very small chance, even if it's not a small chance, it's fine because, like you start doing things and then you lost taxes and you get it. You know an error, it's fine, and even if you not get you, if you don't get an error immediately as long as you do get it eventually in some reasonable time so system converges on some stable state that is in git and then eventually in the database, then it's also fine. I think it's all good.

D

That would be my first thought and if we were really wanted to crack down on it, I think we could have caz recheck the repository after it receives information from rails when it asks if there's access and rail says yes, kaz could recheck the repository and see if that was still there. If we were worried, does that make sense.

C

Let's not slow everything down yeah I mean there are lots.

B

Of cash will have the sorry sorry.

C

There are lots of requests every second and we already memorized this information. We don't put it in redis, but each cast instance uh caches it in memory.

C

For some a few minutes, I don't remember and just to speed things up, because every extra request to even radius is a network open, that's terrible, so the fewer we have and and yeah going to italy to check something on disk is even even worse. I think I don't think it's worth it like it's a super rare thing that doesn't actually lead to any uh terrible consequences, any security consequences or anything actually it was approved. It was revoked system eventually revoked your access, it's normal. It doesn't have to be like, like that. You know.

C

I think it's fine.

C

And here with guitops and accepting ncicano and accepting or denying it's also fine.

C

But we just need to ensure that it eventually converges on the correct state. That's the only property that we need to make sure you know we we what we design it has that property.

C

And I think it will because cost each time it gets an updated commit from the reposition, even not even an updated, commit yeah every time it anyway. It sends the same configuration multiple times occasionally in certain cases, but so eventually it so it will keep spamming basically and the rails if it, even if it had some connectivity problems to the database or whatever, was unavailable or something something or had a bug. Eventually, it will fix the database and eventually the access will be revoked.

C

So it's it's. It's going to fix itself. Basically.

B

So yeah it sounds like we have at least discussed this enough to be aware of it when it gets implemented and that it doesn't seem like any particular architecture is more vulnerable to this than other. It's more.

B

How exactly we choose to implement the architecture because it's like a little edge edge case there, but you could you could do it weird and then it would be weird, but eventual consistency will work.

C

Are you, are you talking about two tables versus one table.

B

Yeah, for example, um like you know like I think I think both of those can work and we, when we don't have to necessarily decide that you know like that. That's something that we could even leave to like the person doing the work, because then they're closer to the code.

C

Any other points that we need to talk about here. um I.

B

Think yeah sorry.

A

Let's just remember we also talked about if you want to weigh in as well on how do we represent uh the groups, for instance on the agent config and like there was a proposal like, for instance, right now. We have manifest projects, we could have manifest groups. This is one option and then you can add groups there.

A

Other option was like having many because when you say manifest projects and the proposal in the issues like you can list groups or projects when you're reading that file, you don't actually know what is a group or a project.

C

Wait why so, why would you go and this is for githubs? So why would you list a group there.

A

uh This is for giving access to agent. I think as though so yeah so not manifest project wouldn't make sense for groups right. You would probably put on the ci.

C

So for ci, yes, it makes sense like give access to all the projects in in this group or in this list of groups, but for githubs like yeah, two, it's per project, because many first time in a project you you're, not gonna, be pulling all projects in the whole group and all the nested groups- and you know, pull everything from all the projects into your cluster.

C

C

Yeah, basically, approval for githubs is only needed on a project level.

A

B

It's it's needed. It's needed from the manifest. The manifest project needs to approve access on on a per agent basis right, so each agent requests access to git ups for a given project. So what, by listing.

B

By listing it as a manifest project and then that project has to grant access for ci it's different, but it's still uh circus, because then there you can list the group and grant access to it. And if we want the ability to exclude certain agents from the cube config, then you may need so at the project level. You may need to go up and look just like when we eventually populate the ci jobs, cube config, you know there.

B

We look at all the groups and all the you know everything that granted me access to this, like every all the agents I have access to. We need to show that also to the user so that they can say no. I don't want my engineers to be able to deploy here and here and here if, if we want to do that, but that's not actually what we should be discussing now, but it's still like relevant it's very similar, but slightly different.

A

But uh also for manifest, I coming back now as well like. We might indeed want to give access to a group. I think, because if you want to, I think that was the idea, at least when we were discussing this morning, because if you have like a yeah, you can set like a template thing. You know idea and ask that you are the projects under that group create manifests under a certain folder or something like that, and then you give access to all of them at once.

A

Instead of having to give access to each one of them, you know so it becomes like a template thing. You give access to a group, that's how we understood at least allow this. Everyone under this group to use, manifests uh githubs and then every project has to put the folder on that uh certain specified path. That's that's how I understand.

B

So then, that that that's a good point actually, but should then so that means um the agent is saying I want like convention across this entire group. I want to say, if you, if you put memphis there, then you're allowed to deploy like that.

B

But then the question is should so you say I allow this group to deploy manifest from this folder or just a deploy, manifest so you're kind of requesting access to their code, but then, on the other side, who is it that grants? Who is it? That proves that? Can you approve it at a group level or does each project have to opt into these kinds of deployments or a mixture.

A

I think in the beginning it would be like a proof 12, that this would be like what I understood as first iteration, so it's approved to everyone, so it starts collecting. I don't know.

E

A

Yeah, that's how I understood at least I don't know if yeah but cool and then the proposal was this and then you would opt out as you as you want. I guess.

C

So I have brag to say things about this and let me say things so: first, I think uh doing the uh grant and then exclude is always a pain in the butt like. Let's not do that for any feature. It's always just simpler to have things that just compose that additive that, like airbag or like.

C

Oh god, uh how is it anyway? Airbag is a good enough example. uh When things just add up and that's how you configure things so adding the grant and then opt-in is always difficult and having it in the database also makes it difficult than to query because you have to consult yet another thing to exclude, you know, do the allow this block list, merge them and just difficult and slow, potentially and then another thing I want to say is that is there actually are there actually people who want this like? Why do they want this?

C

How many people are there who want this? Like point: zero, zero, one percent? Let's not do that. Second, another thing that I want to say: even if there are people with this use case, which I I'm not sure maybe, but there are not many of them- they should probably use some sort of scripting uh to automate this whole thing rather than us building this automation like thing on top as part of the product, and they can use terraform for that.

C

Just have a loop that puts files into the agent configuration repository with the list of projects and have a next loop that approves them in all those projects, and something like that, but actually the problem here is that you can't approve, which hasn't been the request that haven't been processed.

C

So this is not actually declarative. Kind of it's kind of there is order. You first have to cast first has to read this, then it submits. Then you can approve, so it will not play well with terraform, because you will have to like wait until caspix picks it up, but I think the.

A

C

Yeah, I still think that it it's much better to do just for people who need this to just let them do it uh using a script or terraform, and then they get more flexibility in what they can do rather than us building this for a very rare use case. It just complicates everything once you add this feature, you have to do opt-outs and that's it's a pandora's box. Basically, I think we should definitely not do it in the first iteration.

B

So to clarify you don't want to build uh if you don't want to have accommodations for, uh like group level, get ups.

A

B

Like group level get ups requests, or do you mean you don't want them to be auto accepted? You want to always demand project level approvals. If we build it, the.

C

Former, I don't want, I don't think we need this feature like group.

B

E

B

C

Githubs, no, I don't need this. I think, okay, we can always add it later. If people ask for it like, we are not building something that will be incompatible with this. If we, if there is a need actually.

A

Yeah, that's fair. I think it's fair.

B

Like I, I can't see it having an audience because autodevops has an audience, and this is basically lot of devops with githubs, but not quite because it doesn't build your code or anything. It just deploys the manifest but yeah it's like. I can see it appealing to organizations that are very clamped down on what you're allowed to do.

C

But this is google with something like terraform or just a script that you run and it configures everything it takes a list of projects and it configures the agent to pull, manifests from certain directories in those projects.

C

It's still doable, it's just not worth it for to build it. I think.

B

It's it's at least, not something. We should be uh complicated like allowing to complicate the first iteration.

B

Okay, it's like the problem that everyone right now is having is they want cross group uh or and private like private project access and all that, like? That's, that's what we need to solve right now, and uh this would be kind of hijacking that, um with with an extra complexity,.

C

We have more points to talk about, because I need we'll need to go in 10 minutes.

D

I have one more thing: if no one else wants to continue on groups.

D

Okay, I just so I saw there's a point in the ux discussion about showing the path and the response from victor was maybe, after it's accepted, we'll show the path, and this is the gitoff's manifest path. I would expect that if, in your agent configuration project, you changed the path to look for manifest.

D

That would require re-approval, and so therefore, we have to show the parts in the approval process was the expectation that was the expectation that approval means approval for any manifest going forward, no matter what the agent configuration changes to or is it reapproving every time something changes in the configuration project?

D

That's a very good point.

B

And can I ask for some clarifications? So what is the path? Is it a file path, the project path? What are we.

D

The glob that's configured in the agent configuration program project to look for manifest.

D

I would say, we'd have to show that in the approval ui, because the project owner has to say, oh actually, I don't want you to access some other parts of the project and if that glob changes or the globs it could be mini is reapproval required. And I would say yes.

B

D

I agree which makes sense and I think that's fine. um We just need to um experiment with showing those in the ui. I guess.

C

And it's not only the log. Well, maybe it is only globes at the moment, but potentially you know it. It's the whole configuration block for this repository, so we should probably uh like hash it and store the hash and then later compare it with whatever is present in the new configuration, that is, that was sent by class.

C

Something like that.

D

We have precedent for this in the ci access as well ci access stores the um access as configuration, so it's pretty similar to what happens there.

C

A

A

Does it mean that we need one more than multiple access requests to the same project? It's one per glob then, because you can keep one glob and add more globs, for it.

D

I would say to keep it as one and either they're all approved or not.

A

But if you have one previously approved- and uh you add one more glob.

D

A

D

The whole configuration, I would say, yeah, but.

E

Then you lose also, which.

A

Is the left axis.

E

C

Yeah again should lose access, but this is fine because it's github's, it's like nothing, is going to be destroyed or stopped working right. It's just the latency between changes and changes being applied increases until someone clicks tap button.

C

I think this is fine. Okay,.

C

Actually, maybe even like what, if you change it back.

C

Should it be reapproved automatically.

C

C

Maybe we can store this as like last approved hash or something like that and then also a boolean flag if it matches the last configuration.

C

But actually this this approval is not going to be enforced by by cass or by yeah by cass right, like maybe it has been reconfigured.

C

So what I'm saying is kind of ah no okay class runs in the because it is kind of trusted. So it's okay.

C

So I, what I'm saying is cass is not the thing that it evaluates the what has been approved and actually accesses only that no, but it gets the configuration. Sorry, I'm talking to myself, I'm just thinking about it. So cass gets configuration from.

A

C

From rails, when our no at the moment only for ci access, but for gitobs, how does it work.

B

It it gets the project info and then it it just gets things from get directly.

A

B

A special case for the manifest for the configuration project when, like that one's allowed to be private, because you know it's your own project, um I do have a thought regarding the paths does the does it need to be unilateral, so uh you know the agent says I want to allow you to deploy these paths, but they can just put a star you know, but then, and that that's that's in a way.

B

Fine then you're, just saying hey, you can deploy with get ups, put put the manifest wherever you want, and then the project would have to say actually where it wants the manifest to come from. Does that make sense.

C

So currently um agent tells cass which globs it wants.

C

So you see, cass cass can get an approval, but then a rogue agent can send them a star and ask for everything all files in the repository.

C

We can change this, of course, but that's how it works today. The globes are sent by the agent, uh so maybe that has to change. I mean it has to change. If we do this approval for not the whole repository, but only for the globes conceptually.

D

It could be that the approval is that the agent can access this project and it might not have anything to do with the watch files specifically, so it just depends what we want to go with and that way the approval would stand for any future updates. um So we could pick either. I don't know if one's more correct than the other.

C

ah We need to ask that I think it's a kind of a user feature. Ideally it should be as simple as possible and just has access to this project is hopefully good enough, and I mean you are deploying your stuff into this kubernetes cluster that is owned by this infrastructure team. So you don't trust them like you, trust them to run your application, but you don't trust them to access your repository like.

C

Maybe you don't want the repository to be exposed to the whole organization, but your infrastructure team can take down your whole production application. I mean you trust them with much bigger thing already, so why not trust them with looking at your files?

C

So I think this is not worth complicating things.

B

In, in my case, the my concern, my thinking is mainly that different teams may like storing their files in different places.

B

You know bike shedding or where there may be technical limitations based on what tools they are using outside of this whole thing, you know they might have to put manifests three levels deep because of something something you know, because it could be a huge monorepo um but yeah. I don't see why you couldn't just ask the admin administration team to change the globs on that side there there must be some communication channel between the agent owner and the project owners.

C

Wait if there is a monorepo, then you you get. You see everything already. So what the problem, the secrets.

B

No, it's not it's, not a it's not about. uh In my case, it's not about security. It's just about um not making agents. Okay or not. Making agents try to deploy c, plus plus files.

B

You know so, if you have lots of different file pads many different, yaml file kinds, and then you know, the admin team is just like: hey I put a star there enjoy like that's. Obviously they shouldn't put a star there, but there could be.

B

I don't know this is more like if, if we introduce this type of templating thing, so not really a problem right now, when you have to when it's a projected project, connection or agent to.

C

Project connection: we should keep it simple and just do a grant for the whole project, and then we don't need to do re-approval and configuration changes or any of that. Basically.

C

But it's been approved, it can be revoked, but it's been approved, so everything can be accessed by the agent all files in the repository, but it probably once only certain files and that's what is in the agent configuration.

C

That's probably good enough for 90 percent or more. We don't probably care about everybody else.

B

So xiao had to go, but he had a question. We haven't decided on alerts or have we do you know what kind of alerts he is talking about.

D

Was this, uh for example, an email notification that you were that your group has? Someone has requested access, um that's what I took from it. I think either way if that is the case, if that is the thing the feature or if it's not, it's probably still, you know step two.

C

D

We can probably decide that later we don't.

C

Need this most likely, because I mean at least in the first iteration, because you want your files deployed to the cluster, so admins added that configuration so you're in your interest to go and approve, approve that and so, and they can always reach to you via issues or some chat or whatever. So.

D

Maybe not it was probably alerts are probably a bit more of a problem or a requirement when things get auto approved, um but if we're not doing any kind of auto approval, we might not need them well as urgently.

C

Sorry, I also need to go I'll upload. The video.

C

Thank you for the chat. You wait. If I stop, then, if I leave, then you can't continue because I'm recording.

B

No, you can stop the recording and leave okay, it's okay.