Build and run secure applications

• Quality of digital certificates: We will examine two topics that impact quality:
• Quality of technical characteristics (e.g. key generation algorithm, certificate signing algorithm, certificate use, etc.)
• Quality of trust-related characteristics (e.g. issuing certification authority, certification policy, generation procedures, etc.). These are the core components of your PKI.
• Lifetime: Each certificate has a specific lifetime. On reaching its validity end date, services that use it will become unavailable, to prevent you from using expired certificates. Using an expired certificate exposes the server or user to the risk of identity spoofing.

The first step towards covering these two risks must therefore be to write a compliance policy that defines appropriate quality requirements. Thereafter, measures must be taken to uphold the specified quality over time. For example, in 2005, all certificates had to be issued with a basic “sha1” hashing algorithm as standard. Today, the “sha1” algorithm is obsolete and vulnerable. Compliance criteria evolve quickly. As a result, a continuous quality process must be implemented, based on a Plan-Do-Check-Act (PDCA) approach, for example.

As well as addressing the vulnerability of algorithms and the obsolescence of issuance criteria (even for renewals), it is important to uphold compliance over time.

For example, you might initially generate your certificate in the right conditions. When it is renewed a year later, however, you have no guarantee that your operational personnel are still complying with the criteria originally established. The team might not follow the specified renewal procedures. The result would be a non-compliant certificate installed on your platform.

How can we manage this issue?

In this article, we describe how to implement a continuous integration and deployment factory based on BerryCert, enabling you to deliver secure, policy-compliant applications to your customers.

BerryCert will also provide the traceability and validation workflow you need in order to enforce your information system security policies, as well as more demanding standards such as ISO 27001 or PCI-DSS.

This article continues in the form of a guided tutorial, using specimen configurations of the various assets. For greater clarity, we have made the following choices:

• Rather than using a DevOps orchestration tool, we have described a step-by-step process suitable for any computer. (This process could easily be adapted for tools such as Jenkins or GitLabCI.)
• We have chosen Docker for the delivery and packaging format. You could also conduct the process using other formats, such as VM images, for example.
• We are using Apache HTTPD as our target application. The aim is to show the workflow for an application that supports the https communication protocol.

We are also assuming that you have access to a BerryCert account configured with:

• Compliance policy
• Access to your PKI
• Compliance policy
• Issuance policy
• An ID for your agent

For more information on configuring BerryCert, refer to our FAQ (TODO).

Integration at the build stage

The purpose of this step is to build secure images with the https protocol by default, using certificates that are compliant by default. We will be using a multi-stage build technique where we create a build image, execute the build in it, retrieve the result and copy it to the final (production) image. We will create our own certification generation ‘stage’ and copy our certificates to the final image.

Build phase integration strategy

Process

The following steps must be performed in your Dockerfile:

• Inherit your base image: In the base image, we are assuming that you have already enabled https mode, with self-signed certificates, for example. This base image is available here: repo.com/apache:2.4-insecure-alpine
• Download the BerryCert agent: The BerryCert agent is a utility that lets you manage a target application. It can be run either directly, by BerryCert, or manually, in CLI Authentication is required in order to download it. Please request credentials from the Digitalberry support team, and then insert them in the following command, after the curl command’s -u argument.

Note: The agent is distributed in various formats for different target systems (Windows 32 & 64 bits, Linux 32 & 64 bits, and Alpine 32 & 64 bits). Download the appropriate distribution for your base image.

• Run the BerryCert agent: When run with the –auto parameter, the BerryCert agent will perform the following operations:
  • Scan the existing certificates and send them to BerryCert (for traceability reasons)
  • Generate a new key pair in the build image
  • Generate a Certificate Signing Request (CSR) based on the new key pair
  • Send the CSR to BerryCert
  • Wait (in a polling loop) until the CSR is signed
  • Deploy the newly issued certificate

This command must be added to your Dockerfile

The BerryCert agent arguments are as follows:

• Copy the generated directory to the base image:
• Copy the generated assets into a temporary directory (copying the entire tree, not just the files)
• Copy assets from the first image (–from=0) to the second

• Enable SSH: This step will enable subsequent connections by BerryCert for the purpose of managing the life cycle of issued certificates

For enhanced security, we recommend adding an entrypoint.sh that correctly manages the SSH service (ssh key, etc.). For now, we are enabling SSH to allow BerryCert to connect during phase 2 of the process. SSH protocol security is outside the scope of this article.

• Generate the secure image: At this point, you are ready to build your image by entering this command on your terminal:

1docker build . -t local/apache:2.4-secure-alpine

Your image is now available locally; it is secure and you can push it to your production repository.

Several multi-stage building strategies exist; we have chosen this one for our example as it does not require a complete DevOps chain

Benefits

• Deliver Docker images with compliant certificates from the outset
• No need to install complex cryptography tools for your production images, particularly as they are not useful during real-time execution.
• No need to write an additional procedure or add more automation tools in order to install compliant certificates for your https. BerryCert manages the process for you.
• You can create jobs with parameters in order to build development images (e.g. Snapshot or RC) from the development PKI, and Production images from the Production PKI. This means that developers can work in an environment similar to the production environment during the development phase. You can edit the agent’s –usage-id parameter in order to issue certificates with a particular policy.

Limitations

• Renewals are not yet managed at this stage
• In some information systems, you may not have access to the production PKI at the ‘build’ stage. You can use the process to manage development images very similar to the production versions.
• At this stage, you may not yet have the relevant deployment information (e.g. Server name, SAN, etc.)

We are going to describe a supplemental strategy that lets you manage your server instance during the run phase in production.

Integration after deployment

In the previous step, we explained how to build a Docker image with compliant certificates. Now, we are going to deploy this image and manage the certificates for the instance via the BerryCert utility. We have not described the deployment process as part of this step: you may deploy the image however you see fit (e.g. via an SSH connection, Ansible, etc.)

Deployment phase integration strategy

Process

When you have deployed your image, the server must be registered with BerryCert, using REST APIs

• Authentication: You must use your credentials (as your organization’s administrator) to obtain a JWT token. The necessary curl command is as follows:

Response from the server:

Your JWT token is in the id_token field.

• Add the server’s SSH credentials: The necessary curl command is as follows:

Response from the server:

Get the ID of the created object (in the id field); we will be using it in the next step

• Declare the server to BerryCert The necessary curl command is as follows:

Response from the server:

Server management is asynchronous. BerryCert will attempt to connect a few minutes after receiving the query.

Now that your server is being managed by the BerryCert utility, you will see it in the server list. The workflow that you configured for BerryCert will be applied. If automatic management is enabled, your server’s certificates will be renewed and deployed according to your compliance policy and their validity dates. For more information on configuring these settings, refer to our FAQ (TODO) here.

Benefits

This phase supplements the initial build phase by adding your server to your BerryCert workflow. BerryCert will manage it in future. A fully-automated workflow might look like this:

• Run scheduled, routine scans on all registered servers
• Perform scheduled, periodic renewals of certificates that are:
  • not compliant with the specified compliance policy
  • soon to expire (within 15 days)
• Periodically and continuously deploy all renewed certificates

Conclusion : 

This detailed article explains, step-by-step, how to integrate the BerryCert utility in order to deliver secure Docker images and continue to manage them post-deployment. Although we used Apache https and docker for our example, our BerryCert agent and APIs allow the approach to be adapted for all types of infrastructures, allowing easy integration. Please contact us if you have any questions. We will be happy to help you integrate BerryCert into your infrastructure.