GitLab Compliance Group - Meetings, 15 Jun 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: GitLab Compliance Pipelines & Overriding Settings

Description

Sam Kerr discusses compliance pipelines and how to ensure that compliance pipeline jobs are not able to be modified by downstream projects.

Product documentation with example showing best practices - https://docs.gitlab.com/ee/user/project/settings/index.html#compliance-pipeline-configuration

A

Hi, I'm sam kerr, I'm a principal product manager here at git lab in this video. I wanted to talk to you today about gitlab's compliance framework, feature compliance pipelines and how you can ensure that the job definitions you put in those compliance pipelines aren't overridden unintentionally, and so what I'm sharing here is a project called application development project that we might imagine a development team is working in you can see. It also has a demo framework compliance framework label applied to it and what that demo framework compliance framework is pointing to is to another project.

A

We have called compliance demo project that all it has is a single file. This compliancejobs.um fund inside of compliancejobs.yaml we're defining a single job of a compliance job that runs in our dot pre-stage and is just saying hello from the compliance team. The intention of this is that this job is always going to run the net.prestage.

A

Add that message. It's going to print that message and then include the project specific pipeline configuration file, and so, if we look at our application development project again, we can take a look at our latest pipeline. That's running, and we can see that indeed, we have our build, my job, which is from the application project, and we can see the a compliance job which is from the compliance framework and inside of there sure enough. We have this hello from the compliance team, and this is great. Things are working as expected.

A

The compliance jobs are automatically being added to the pipeline, even though inside the project there's no compliance job or anything explicitly being done here. But what I wanted to talk to you about today was what, if someone, either intentionally or otherwise wanted to make changes to that compliance project.

A

Job inside of the development project pipeline configuration at gitlab. We feel this is something that should not be possible, and that's really what we've designed the feature around and to do that. What we've done is we've said that anything that you explicitly define in a job configuration as part of that pipeline definition cannot be changed. It cannot be overridden by development project.

A

So let's just say that a developer in the application development project went in copied the job configuration and instead of hello from the compliance team. They wrote something like hello from sam: let's go ahead, commit this run a pipeline, see what's going to happen.

A

So once the job's completed, we can again see that, even though we wrote hello from sam, we still get that hello from the compliance team message and that's great it's working just as intended, and so that's going to show that if a developer in this project tries to override that setting it's going to respect what has been defined in the compliance pro compliance team project instead, but let's try making a change to something that wasn't explicitly defined in the compliance project and see what happens there.

A

So, let's add a before script, we can just echo sam was here in the before script.

A

Can you imagine what's going to happen next, let's run the pipeline, we'll take a look and see what happens.

A

And so now, in this job output, we can see a couple things still our hello from the compliance team message is present, but we can also see sam was here in the before script, and so this means that I, as a developer in that project, was able to make changes to the way that the compliance team's job definition was run, and this is incredibly flexible, it's incredibly powerful, but it can be dangerous. If is if this isn't?

A

What you want in your own jobs gitlab provides this sort of flexibility for people to extend compliance jobs in case there are project, specific configurations that you'd, like teams to add, or if you want to do things differently between one project to another, but we also understand that this opens the door to people changing those compliance job configurations in a way you might not find desirable, and so, if we go back to our compliance jobs configuration that's what makes it so important to explicitly define everything in this job that you do not want to change.

A

We have a good reference example in our product documentation, I'll leave a link to it in the description below, but I'll also go ahead and copy it, and we can review it together.

A

So what I've copied in is this compliance print job, and this is showing a number of the different job attributes that we recommend you set explicitly. If you don't want downstream projects modifying the compliance job, so we'll start with the stage. This just ensures that the job runs where you want it to run. We looked at this already this next one is really important. It's our rules and we're saying it to win.

A

Always if you don't set this, it's going to be possible for someone to change the value of this rules and possibly set it to never put it to some conditional that you don't find desirable and that's not going to be possible once you explicitly set it.

A

We also recommend explicitly saying a container image that you want your compliance, jobs to run in it's possible. Different container images might run your compliance job differently, and so using a known, good state will help ensure that your job behaves as intended.

A

We looked at the before script previously, and this is important just to make sure that no one can add a script before your compliance chart runs saving the script attribute to actually explicitly run. The steps of your job is important, similar to a before script. Saying an after script is important.

A

The next two can kind of be dependent on what you want to do with your specific job as well. In this example, I've put allow failure equals false, and this is because, for this example, job that I'm showing you I as a compliance person, would want the pipeline to fail if this compliance job did not pass depending on what you're doing in your own pipelines, you may want to set this to true.

A

You may want to set it to false, but the key here is that if you explicitly set a value, it's the compliance team and that compliance pipeline saying the value rather than allowing it to possibly be overridden by a downstream project.

A

So now that we've taken a look at this, let's go ahead and try applying some of these attributes to our compliance job and we'll try rerunning the development project. Job with all the sam was here sort of messages, so we can just copy these in.

A

We can delete the example that I was showing and again we have our stage. We have our rules, our image, our before script, script after script, allow failure and interruptable.

A

Let's go ahead and commit those changes.

A

Now, if we go back to our we're back in the application development project here, if we rerun our pipeline, let's see what happens in this case.

A

So we can go into our a compliance job, we'll notice that one thing right off the bat we're using that ruby, 2.6 image that we previously defined in the compliance pipeline configuration.

A

All right and now our job has completed running and we'll take a look at some of the different things that we can see in this output. We'll see that the compliance job has explicitly said no before scripts, so that sam was here, message is no longer present.

A

We see our hello from the compliance team and we see our no after scripts message, and so this really shows how you can explicitly set up the configuration of your compliance jobs to not allow them to be overridden by a downstream project, whether intentionally or unintentionally, to change those settings.

A

And so hopefully this has been helpful to you uh again I'll, put a link in our description to the product documentation, which has a lot more information. um If you have any questions, comments or feedback, we'd love to hear from you again, my name is sam kerr. You can tag me at st kerr on gitlab or any of the other members of the compliance team and we'd be happy to have a discussion. Thank you. So much have a good day.