Forem: Gabriel Batista

Using Secure Base Images

Gabriel Batista — Wed, 12 Jun 2024 01:25:32 +0000

I wrote this article to share a bit of what I've learned in the PICK from LinuxTips. So, grab your drink and join me.

It all started when, sometimes, security tools reported low/mid vulnerabilities, and when we went to assess what these vulnerabilities were, we always ended up in the mental agreement: "it's not something we did, so there's no way to fix it."

During the PICK classes, I got to know Chainguard. And then the idea came up to write this article to show how to use a secure base image to build the container for my application.

To demonstrate this, we will containerize a very basic console application of "hello world" in DotNet throughout this article, as the focus here is on how to build a Dockerfile for the application in a more secure way, not the application itself.

Creating the application

Assuming you already have the DotNet SDK installed and configured in your environment, let's open our terminal and start creating the project.

We will create our application using the console template of the DotNet CLI. We will do this using the following command:

dotnet new console -o HelloWorldApp

Once this is done, let's move to our favorite text editor to start manipulating the files contained in the project directory.

With your text editor open, let's modify the Program.cs file to have our Hello World. Edit your file to look like the following:

namespace HelloWorldApp
{
    static class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Hello World!");
        }
    }
}

Creating the Dockerfile

Perfect, now that you have created our application (which has the potential to hack NASA), it's time to create our Dockerfile to containerize our application.

It is worth remembering that the Dockerfile needs to be at the same level as the csproj file, in our case, inside the HelloWorldApp directory.

To build our Dockerfile, in addition to using secure base images, we will use an organization and performance concept called multi-stage builds.

First stage

Without further ado, let's move to the first line of our Dockerfile:

FROM cgr.dev/chainguard/dotnet-sdk:latest AS build

The base image we are using has a reduced scope so that there are only dependencies that satisfy the use of the DotNet SDK.

Therefore, compared to the scope of a base alpine image, for example, the chances of our container having vulnerabilities that do not pertain only to the DotNet SDK dependencies are much smaller. And this is the great advantage of using Chainguard's base images.

Still, regarding the first line, note that we used an alias to identify the stage that will be executed. In this case, we called the current stage build.

Moving on, so that we can execute our command that will compile our application and generate our dll (dotnet publish), we need to first declare that our files belong to a non-root user so they can be compiled. We will do this as follows:

COPY --chown=nonroot:nonroot . /source

Here we are using the COPY command to copy all the files from the current directory where the Dockerfile is located, under the permissions of a non-root user, to a directory inside the container called source which will be used later.

Since it is a secure base image, some operations (such as publish in our case) require a little more attention to permission levels, since letting things be compiled at a high level would undermine the security of the image.

At the end of this stage, we will define our default working directory and carry out the process of creating our dll, which will be directed to a directory called Release. This will be done in the following lines:

WORKDIR /source
RUN dotnet publish --use-current-runtime --self-contained false -o Release

Final stage

Now, in this stage, we no longer need dependencies related to the SDK; we now need resources related to the DotNet runtime to run our dll. For this, we will use the following base image:

FROM cgr.dev/chainguard/dotnet-runtime:latest AS final

After this, we will proceed to define our default working directory and now use the great advantage of using multi-stage. As in the build stage, we have already generated our dll; we can now copy our dll to the current stage to use it. We will do this as follows:

WORKDIR /
COPY --from=build /source .

Note that in the COPY command we are stating that we want what was generated in the /source directory of the build stage to be copied to the root context .. And this is where we gain organization and performance in our Dockerfile, segmenting the creation and reuse of artifacts.

Finally, we will define our main command that will be executed when our container starts, that is, we will indicate that we use DotNet to run our dll. We do this as follows:

ENTRYPOINT ["dotnet", "Release/HelloWorldApp.dll"]

Complete Dockerfile

With all this done, our final Dockerfile should look like the following:

FROM cgr.dev/chainguard/dotnet-sdk:latest AS build
COPY --chown=nonroot:nonroot . /source
WORKDIR /source

RUN dotnet publish --use-current-runtime --self-contained false -o Release

FROM cgr.dev/chainguard/dotnet-runtime:latest AS final
WORKDIR /
COPY --from=build /source .

ENTRYPOINT ["dotnet", "Release/HelloWorldApp.dll"]

Building and Running the Image

With our Dockerfile created, it is time to build our image and see if everything works as expected (this is usually where everything catches fire). To do this, being in the same directory where our Dockerfile is, we will run the following command:

docker build -t helloworldapp .

Once the build is complete, let's move to the most awaited moment: running a container that will have our dll being executed. To do this, use the command:

docker run --rm helloworldapp

That's All, Folks

This concludes our journey with the use of secure base images and multi-stage Dockerfiles. Clearly, you can venture further, for example, by creating GitHub workflows that scan the code or container with each push/pull request using tools like Snyk or Trivy.

Now it's up to you: abuse and use what we've covered here! Explore other base images, try to understand more how they work, try refactoring Dockerfiles to use multi-stage. Go beyond!

Remember: may the force be with you, live long and prosper, and don't panic! Allons-y!

Usando Imagens Base Seguras

Gabriel Batista — Wed, 12 Jun 2024 01:25:28 +0000

Escrevi este artigo para compartilhar um pouco do que já aprendi no PICK da LinuxTips. Então, pegue sua bebida e me acompanhe.

Tudo começou quando, por vezes, as ferramentas de segurança reportavam vulnerabilidades low/mid e, quando íamos avaliar o que era essa vulnerabilidade, nós sempre acabávamos no grande acordo mental: "não é algo que a gente fez, então não tem como resolver".

Durante as aulas do PICK, conheci a Chainguard. E aí surgiu a ideia de montar este artigo para mostrar como utilizar uma imagem base segura para construir o container da minha aplicação.

Para mostrar isso, vamos containerizar uma aplicação de console bem básica de "hello world" em DotNet ao longo deste artigo, visto que o foco aqui é como montar um Dockerfile para a aplicação de forma mais segura e não a aplicação em si.

Criando a aplicação

Assumindo que você já tenha o SDK do DotNet instalado e configurado em seu ambiente, vamos abrir nosso terminal e começar a criação do projeto.

Vamos criar nossa aplicação usando o template console da CLI do DotNet. Faremos isso utilizando o comando a seguir:

dotnet new console -o HelloWorldApp

Feito isto, vamos para nosso editor de texto preferido para começar a manipular os arquivos contidos no diretório do projeto.

Com seu editor de texto aberto, vamos alterar o arquivo Program.cs para que ele tenha nosso "Hello World". Edite seu arquivo para que ele se pareça com o seguinte:

namespace HelloWorldApp
{
    static class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Hello World!");
        }
    }
}

Criando o Dockerfile

Perfeito, agora que você criou nossa aplicação (que tem potencial para hackear a NASA), é hora de criarmos nosso Dockerfile para containerizar nossa aplicação.

Vale lembrar que o Dockerfile precisa ficar no mesmo nível do arquivo csproj, no nosso caso, dentro do diretório HelloWorldApp.

Para construir nosso Dockerfile, além de utilizar imagens base seguras, vamos utilizar um conceito de organização e performance chamado multi-stage builds.

Primeira etapa

Sem mais delongas, vamos para a primeira linha do nosso Dockerfile:

FROM cgr.dev/chainguard/dotnet-sdk:latest AS build

A imagem base que estamos utilizando possui um escopo reduzido para que apenas haja dependências que satisfaçam o uso do SDK do DotNet.

Portanto, se comparado com o escopo de uma imagem base alpine, por exemplo, as chances de nosso container ter vulnerabilidades que não dizem respeito apenas às dependências do SDK do DotNet são bem menores. E este é o grande diferencial de utilizar as imagens base da Chainguard.

Ainda sobre a primeira linha, perceba que utilizamos um alias para identificar a etapa que será executada. Neste caso, chamamos a etapa atual de build.

Seguindo em frente, para que nós possamos executar nosso comando que irá compilar nossa aplicação e gerar nossa dll (dotnet publish), precisaremos antes declarar que nossos arquivos pertencem a um usuário não root para poderem ser compilados. Faremos isto da seguinte forma:

COPY --chown=nonroot:nonroot . /source

Aqui estamos utilizando o comando COPY para copiarmos todos os arquivos do diretório atual onde está o Dockerfile, sob as permissões de um usuário que não é root, para um diretório dentro do container chamado source que será utilizado posteriormente.

Por se tratar de uma imagem base segura, algumas operações (como o publish no nosso caso) requerem um pouco mais de atenção a níveis de permissão, visto que deixar coisas serem compiladas a um nível elevado levaria por água abaixo toda a segurança da imagem.

Ao final desta etapa, vamos definir nosso diretório de trabalho padrão e realizar o processo de criação da nossa dll que será direcionada para um diretório chamado Release. Isto será feito nas linhas a seguir:

WORKDIR /source
RUN dotnet publish --use-current-runtime --self-contained false -o Release

Etapa final

Agora, nesta etapa, não precisamos mais que haja dependências relacionadas ao SDK; precisamos agora ter recursos referentes ao runtime do DotNet para executar nossa dll. Para isso, vamos utilizar a seguinte imagem base:

FROM cgr.dev/chainguard/dotnet-runtime:latest AS final

Após isso, vamos então partir para a definição do nosso diretório de trabalho padrão e vamos agora utilizar a grande vantagem de se utilizar o multi-stage. Como na etapa de build nós já geramos a nossa dll, podemos então copiar nossa dll para a etapa atual para podermos utilizá-la. Vamos fazer isso da seguinte forma:

WORKDIR /
COPY --from=build /source .

Perceba que no comando COPY estamos informando que queremos que seja copiado para o contexto raiz . o que foi gerado no diretório /source da etapa build. E é aí que ganhamos organização e performance em nosso Dockerfile, segmentando a criação e reutilização de artefatos.

Por fim, vamos definir qual será nosso comando principal que será executado quando nosso container for iniciado, ou seja, vamos indicar que usemos o DotNet para executar nossa dll. Fazemos isso da seguinte forma:

ENTRYPOINT ["dotnet", "Release/HelloWorldApp.dll"]

Dockerfile Completo

Com tudo isso feito, nosso Dockerfile final deve se parecer com o seguinte:

FROM cgr.dev/chainguard/dotnet-sdk:latest AS build
COPY --chown=nonroot:nonroot . /source
WORKDIR /source

RUN dotnet publish --use-current-runtime --self-contained false -o Release

FROM cgr.dev/chainguard/dotnet-runtime:latest AS final
WORKDIR /
COPY --from=build /source .

ENTRYPOINT ["dotnet", "Release/HelloWorldApp.dll"]

Build e Execução da Imagem

Com nosso Dockerfile criado, é hora de fazer o build da nossa imagem e ver se tudo funciona como o esperado (geralmente é aqui que tudo pega fogo). Para fazer isso, estando no mesmo diretório onde nosso Dockerfile está, vamos executar o seguinte comando:

docker build -t helloworldapp .

Após o build concluído, vamos para o momento mais aguardado: a execução de um container que possuirá nossa dll sendo executada. Para isso, utilize o comando:

docker run --rm helloworldapp

Isso É Tudo, Pessoal

Isto conclui nossa jornada com o uso de imagens base seguras e multi-stage em Dockerfiles. Claramente, você pode se aventurar indo além, por exemplo, criando workflows no GitHub que fazem o scan do código ou do container a cada push/pull request usando ferramentas como o Snyk ou o Trivy.

Agora é com você: abuse e use o que passamos por aqui! Explore outras imagens base, tente entender mais como funcionam, tente refatorar Dockerfiles para utilizar multi-stage. Vá além!

Lembre-se: que a força esteja com você, tenha uma vida longa e próspera e não entre em pânico! Allons-y!