科技动态

Securing your CI/CD pipeline

微信扫一扫,分享到朋友圈

Securing your CI/CD pipeline
0

You

Everything starts with you, the author. You make changes, commit them and push them to the central repository. Standard procedure. But how will others know that you made those changes? You configure your Git command, of course.

$ git config --global user.name "John Doe"
$ git config --global user.email "[email protected]"

But can this be trusted? Are you really John Doe? Or someone else with malicious intent who tries to frame poor John? Due to the decentralized nature of Git, we can’t be sure. There is no central authority who can clearly validate your claim. Fortunately you can GPG sign your commits
to prove yourself. Now others can verify your commits if they have your public key.

Central repository

The central repository does not care about the author metadata of your commit. It does not even care about your GPG signature. Usually the central repository has other means to prove that you are who you claim you are. It can be for example the user name and password of your account, an API token or SSH key. The central repository will only check that you have access to the repository you try to push to. It won’t check the content of your push by default.

What can you do to change that? It depends on the actual service you use. Most often repository access can be restricted both on individual or on team level and it’s a good practice to provide the least privilege
. But maybe you can go even further. For example in Gitlab Enterprise there are push rules
you can turn on to check whether the commit author’s email address belongs to any user in the system or the commit is GPG signed. You can even reject commits which are not committed by the currently authenticated user, but depending on your workflow this could be a bad idea.

Build server

Can you trust in the central repository? Maybe. But why would you do that? Let’s assume that your project has a policy that every commit must be signed by someone. In that case you can setup your build to fail if it finds a commit with invalid signature or no signature at all. So you can validate the content you get from the central repository, no trust is required.

The build server should only access repositories and production machines it needs to access. Different projects should use different credentials in both directions so Project A cannot access Project B’s repository and machines.

Eventually you will have a successful build. The build server can even create a GPG signed tag to prove that and push it back to the repository. It’s time to create a Docker image which contains our trusted application code (or created binaries) from the repository. Luckily the build server can also sign the created image tag
before pushing it to the registry.

Docker registry

The least interesting part of the pipeline. It’s similar to the central repository but we have even less things to fiddle with. Push should be restricted to the build server and pull should be restricted to the production servers.

Production servers

When the production server pulls the image from the Docker registry it can verify that it’s indeed signed by the build server and if everything is all right it can switch to it. Congratulations, your code has arrived to production.

There is just one little problem left. Despite all your efforts so far your code can still be modified by someone who has proper access to the production servers. So the number of people who can access the production servers and have the privilege to change the code (write access to the files or access to the docker command) should be minimized and unplanned modifications should be logged.

What could go wrong?

In the above scenario, the build server trusts you (or rather your GPG signature) and the production server trusts the build server. So the two weak links in the chain is you and the build server.

You are human, so you make mistakes. Forget to lock your machine or lose your laptop and someone can access your SSH and GPG keys. Hopefully they are all password protected, but chances are that you use agents to save yourself from some password typing so our hypothetical evildoer can create a signed commit in your name.

But what if you are the evildoer? What a twist in the story! If you want to intentionally break the code and sign it, you absolutely can. Other processes like merge requests with mandatory approval by other people can prevent this or at least lower the chances. In this case the trust is distributed amongst the reviewers and the central repository (which provides the tools for the approval process).

The build server is a little bit more complicated. It is after all remote code execution by design. The best you can do is to know your software of choice and separate the projects as thoroughly as possible. For example use a credential store and limit access to project specific credentials to the project only. You can even create separate build servers for more sensitive projects.

What’s next?

Can’t wait to begin to reform your pipeline? Start with the smaller things first like reviewing and tightening the privileges at each step to have a solid foundation. Afterwards you can introduce the more complex pieces like a review process or signing and signature validation.

There are always opportunities to make your pipeline even more secure, but every extra layer brings its own complexity to the system. You have to find a fine balance between security and usability that works for your use cases and your team.

阅读原文...

微信扫一扫,分享到朋友圈

Securing your CI/CD pipeline
0
Avatar

Kafka Blindness

上一篇

Working With Kafka At Scale

下一篇

评论已经被关闭。

插入图片

热门分类

往期推荐

Securing your CI/CD pipeline

长按储存图像,分享给朋友