Software always requires access to sensitive information such as user data, credentials, Open Authorization (OAuth) tokens, passwords, and other information known as secrets. Developingand managing software while keeping all these aspects secure has always been a concern. The CI/CD pipelines might deal with them as they build and deliver working software by combining code and other dependencies from various sources that may include sensitive information. Keeping these bits secure is of utmost importance; therefore, the need arises to use modern DevOps tools and techniques to embed security within the CI/CD pipelines themselves.
Most application code requires access to sensitive information. These are called secrets in the DevOps world. A secret is any data that helps someone prove their identity, authenticate, and authorize privileged accounts, applications, and services. Some of the potential candidates that constitute secrets are listed here:
- Passwords
- API tokens, GitHub tokens, and any other application key
- Secure Shell (SSH) keys
- Transport Layer Security (TLS), Secure Sockets Layer (SSL), and Pretty Good Privacy (PGP) private keys
- One-time passwords
A good example could be a container requiring access to an API key to authenticate with a third-party API or a username and password to authenticate with a backend database. Developers need to understand where and how to store secrets so that they are not exposed inadvertently to people who are not supposed to view them.
When we run a CI/CD pipeline, it becomes imperative to understand how we place those secrets as, in CI/CD pipelines, we build everything from the source. “Do not store secrets with code” is a prominent piece of advice we’ve all heard.
Tip
Never store hardcoded secrets within CI/CD pipelines or store secrets in a source code repository such as Git.
How can we access secrets without including them in our code to run a fully automated GitOps-based CI/CD pipeline? Well, that’s something we need to figure out.
Tip
When using containers, the thing to avoid is baking the secrets within an image. While this is a prominent piece of advice, many developers do this inadvertently, leading to many security holes. It is very insecure, and you should avoid doing it at all costs.
You can overcome this problem by using some form of secrets management solution . A secrets management solution or a key management solution helps store and manage your secrets and secure them with encryption at rest and in transit. There are secrets management tools within cloud providers, such as Secret Manager in GCP and Amazon Web Services (AWS), or you can use a third-party tool, such as HashiCorp Vault, if you want to go cloud agnostic. All these solutions provide APIs to create and query secrets at runtime, and they secure the API via HTTPS to allow encryption in transit. That way, you don’t need to store your secrets with code or bake it within an image.
In this discussion, we’ll use the Secret Manager solution offered by GCP to store secrets, and we will access them while running the CI/CD pipeline. Secret Manager is Google Cloud’s secrets management system, which helps you store and manage secrets centrally. It is incredibly secure and uses Hardware Security Modules (HSMs) to harden your secrets further.
In this chapter, we will look at improving the CI/CD pipeline of our Blog Application, which we discussed in the last chapter, and will use the same sample application. Therefore, let’s go ahead and create the mongodb-creds Secret in Google Cloud Secret Manager.
