-
Notifications
You must be signed in to change notification settings - Fork 2
Home
The CICD-toolbox is a set of tools that can help getting started with a CI/CD pipeline. It is intended as a starting point and intended for non-devops engineers that need the tooling, but have experienced that is is too difficult to set up such a tool chain themselves.
Devoteam is experienced in setting up such tool chains and through this repo we share that knowledge.
For us, this is also a playground in which we experiment, therefore:
When you are running IT services, such as any IT department of a company, there comes a point where you think: "What if we have to start from scratch? What would we do?". For some companies, this is no longer a hypothetical question. After a ransomware attack they were faced with exactly that Problem (capital P intended).
What you want in both cases is to quickly spin up a newly created environment which is safe, maintainable and easy to use. There are several options here, such as Otomi, Backstage and others, but these require an operational infrastructure. And the assumption here is you do no longer have that.
If you start out with nothing and want to be operational fast, you need to split the work in pieces that can be prepared because they are relatively static, and parts that are dynamic. If you look at your infrastructure that way, a lot of stuff turns out to be, or can be made static. Application configuration is normally pretty static as this is linked to the processes in your organization. Application authorization is generally linked to application roles, not users as such. And thus also pretty static. And application roles link back to teams and thus to the organizational structure, which - hopefully - is also pretty static.
Login to applications is going towards Single-Sign-On (SSO), which leverages this situation: SSO tools such as Keycloak link back to a directory, where the user to group mapping is stored.
In the case of an emergency, this user to group mapping can be recreated on the back of a beer mat by any team lead, manager or team member. In the CICD Toolbox, we therefore use a very, very basic directory: LLDAP, a very lightweight implementation where the basic groups you would expect in any IT organization, are configured. There is no nesting of groups.
As we need to log on to systems, we need secrets: usernames and passwords, digital identities, etc. Hashicorp Vault is a PKI for digital identities and a Key Value store for usernames and passwords.
We also use Keycloak for Single Sign On and so the order in which this tooling is installed matters a lot.
No data is - or rather - should be stored locally. Local data is not accessible for your peers. Instead, a revision control system should be used. In a revision control system you store your changes and collect review comments from your peers. The currently most used revision control system is called git and is available from multiple vendors and open-source repositories.
Git is used to enforce the 4-eyes principle when releasing new versions of configs and automated processes. The 4-eyes principle ensures that a single user cannot put changes into production that have not been peer-reviewed.
The CICD-toolbox uses Gitea as git server. Gitea is chosen because the open-source version of the CICD-toolbox should be able to run locally. Gitea is light weight and offers almost all functionality needed.
The architecture of the CICD-toolbox is geared towards security by design and recovery in the case of a disaster. In this approach, IAM is separated into three separate pillars: Users to groups, groups to roles and roles to rights (authorization). The first pillar is dynamic, the latter two can be re-created from a pipeline script, as this contains the basic RBAC model towards the infrastructure, which is relatively stable and independent of the organization.
Recovery in case of a disaster is then relatively easy. The pipeline can be re-created from code, containing the group to role mappings and the role to rights mappings. Managers can quickly recreate groups of their employees.
In order to ease the use and increase security, Single-Sign-On (SSO) is standard. Keycloak is used as IAM system and authenticates the user. In the process it provides an identity token to the user. With this token, the user can identify itself at an application, and the application can retrieve the rights from the IAM system. This makes it possible to centrally manage the identity token, providing means to quickly react if anomalities are reported.
By limiting the lifetime of access tokens for an identity token to single-use, attacks relying on token theft in applications become significantly harder.
As the toolbox is aimed at local execution, users are initially still configured in Keycloak to prevent additional containers from being spun up.
A CI/CD solution is incomplete without some sort of orchestration tool. An orchestration tool stitches all actions together and makes a nice report out of it. It allows you to repeatedly execute jobs and test the outcome. This way you can make sure that the systems you use to create the environment that must keep your company's information safe are controlled from the moment they are created. It allows to do proper life cycle management on these systems and test them before deployment.
A common tool for this is Jenkins. It has an almost endless list of plugins in order to ease the work and interconnect with other systems.
In addition to a repository where you store your code, process descriptions and other texts that need to be maintained, you'll need a second kind of repository: a place where you can store data that should not be tampered with. The CICD-toolbox uses this repository extensively, for example to store test reports from test- and deployment runs.
In addition, this repository can be used to store validated versions of the containers used in the setup. These container versions are imported from Docker Hub by default, but you can choose to pull them yourself and vet them before committing them to the repository. This way you can prevent so-called supply-chain attacks: you can make sure the containers have no hidden malware on board.
Next to this, you can circumvent the rate limiting Docker Hub has imposed on the number of pulls you can do per 6 hours.
The CICD-toolbox uses the well known Sonatype Nexus (community edition) as repository.
Portainer allows to manage the NetCICD Toolbox from a Docker perspective, eliminating the need for a myriad of tools on the host machine.
Devoteam. Tech for people.