Proteger contêineres do SQL Server no Linux

Aplica-se a: SQL Server no Linux

Contêineres do SQL Server 2017 (14.x) são iniciados como o usuário raiz por padrão, o que pode causar algumas preocupações de segurança. Este artigo aborda as opções de segurança disponíveis ao executar contêineres do SQL Server no Linux e como criar um contêiner do SQL Server como um usuário não raiz.

Os exemplos neste artigo pressupõem que você esteja usando o Docker, mas você pode aplicar os mesmos princípios a outras ferramentas de orquestração de contêiner, incluindo o Kubernetes.

Criar e executar contêineres sem privilégios de root do SQL Server 2017

Siga estas etapas para criar um contêiner do SQL Server 2017 (14.x) que inicia como o usuário mssql (não-root).

1. Baixe o Dockerfile de exemplo para contêineres do SQL Server não raiz e salve-o como Dockerfile.

2. Execute o seguinte comando no diretório que contém o Dockerfile para construir o contêiner SQL Server não root:

   cd <path to Dockerfile directory>
   docker build -t 2017-latest-non-root .
   

3. Inicie o contêiner.

   Importante

   A variável de ambiente SA_PASSWORD foi preterida. Use MSSQL_SA_PASSWORD em seu lugar.

   docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=<password>" --cap-add SYS_PTRACE --name sql1 -p 1433:1433 -d 2017-latest-non-root
   

   Note

   O flag --cap-add SYS_PTRACE é necessário para contêineres de SQL Server sem privilégios de root gerarem despejos para fins de solução de problemas.

4. Verifique se o container está rodando como um usuário não root:

   docker exec -it sql1 bash
   

   Execute whoami, que retorna o usuário em execução dentro do contêiner.

   whoami
   

Executar o contêiner como um usuário não raiz diferente no host

Para executar o contêiner do SQL Server como um usuário não raiz diferente, adicione o sinalizador -u ao comando docker run. O contêiner não raiz tem a restrição de que precisa ser executado como parte do grupo root, a menos que um volume seja montado em /var/opt/mssql, ao qual o usuário não raiz tenha acesso. O grupo root não concede permissões de raiz extras ao usuário não raiz.

Executar como um usuário com UID 4000

Você pode iniciar o SQL Server com uma UID personalizada. Por exemplo, o seguinte comando inicia o SQL Server com UID 4000:

docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=<password>" --cap-add SYS_PTRACE -u 4000:0 -p 1433:1433 -d mcr.microsoft.com/mssql/server:2019-latest

Executar o contêiner não raiz como o usuário raiz

Você pode rodar o contêiner não-root como usuário root, se necessário, o que também concede automaticamente todas as permissões de arquivo ao container, porque ele tem privilégios maiores.

docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=<password>" -u 0:0 -p 1433:1433 -d mcr.microsoft.com/mssql/server:2019-latest

Executar como um usuário na sua máquina host

Você pode iniciar o SQL Server com um usuário existente no computador host com o seguinte comando:

docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=<password>" --cap-add SYS_PTRACE -u $(id -u myusername):0 -p 1433:1433 -d mcr.microsoft.com/mssql/server:2019-latest

Executar como um usuário e grupo diferentes

Você pode iniciar o SQL Server com um usuário e um grupo personalizados. Neste exemplo, o volume montado tem permissões configuradas para o usuário ou o grupo no computador host.

docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=<password>" --cap-add SYS_PTRACE -u $(id -u myusername):$(id -g myusername) -v /path/to/mssql:/var/opt/mssql -p 1433:1433 -d mcr.microsoft.com/mssql/server:2019-latest

Configurar permissões de armazenamento persistente para contêineres não raiz

Para permitir que o usuário não root acesse arquivos de banco de dados que estejam em volumes montados, certifique-se de que o usuário ou grupo sob o qual você executa o contêiner possa ler e gravar no armazenamento persistente de arquivos.

Você pode obter a propriedade atual dos arquivos de banco de dados com este comando.

ls -ll <database file dir>

Execute um dos comandos a seguir se o SQL Server não tiver acesso aos arquivos de banco de dados persistentes.

Conceder ao grupo raiz acesso de leitura/gravação aos arquivos de banco de dados

Conceda as permissões do grupo raiz aos seguintes diretórios para que o contêiner do SQL Server não raiz tenha acesso aos arquivos de banco de dados.

chgrp -R 0 <database file dir>
chmod -R g=u <database file dir>

Definir o usuário não raiz como o proprietário dos arquivos

O proprietário pode ser o usuário não raiz padrão ou qualquer outro usuário não raiz que você gostaria de especificar. Neste exemplo, você define o UID 10001 como o usuário não raiz.

chown -R 10001:0 <database file dir>

Criptografar conexões com os contêineres do SQL Server no Linux

Para criptografar conexões com os contêineres do SQL Server no Linux, você precisará de um certificado com os requisitos a seguir.

A seguir está um exemplo de como a conexão pode ser criptografada para os contêineres do SQL Server no Linux. Aqui você usa um certificado autoassinado, que não deve ser usado para cenários de produção. Para esses ambientes, você deve usar certificados de Autoridade Certificadora.

1. Crie um certificado autoassinado, que é adequado somente para ambientes de teste e de não produção.

   openssl req -x509 -nodes -newkey rsa:2048 -subj '/CN=sql1.contoso.com' -keyout /container/sql1/mssql.key -out /container/sql1/mssql.pem -days 365
   

   No exemplo de código anterior, sql1 é o nome do host do contêiner de SQL, portanto, ao se conectar a esse contêiner, o nome usado na cadeia de conexão será sql1.contoso.com,5434. Você também deve garantir que o caminho /container/sql1/ da pasta já exista antes de executar o comando anterior.

2. Certifique-se de definir as permissões corretas nos arquivos mssql.key e mssql.pem, para evitar erros ao montar esses arquivos no contêiner do SQL Server:

   chmod 440 /container/sql1/mssql.pem
   chmod 440 /container/sql1/mssql.key
   

3. Agora crie um mssql.conf arquivo com o conteúdo a seguir para habilitar a criptografia iniciada pelo servidor. Para criptografia iniciada pelo cliente, mude a última linha para forceencryption = 0.

   [network]
   tlscert = /etc/ssl/certs/mssql.pem
   tlskey = /etc/ssl/private/mssql.key
   tlsprotocols = 1.2
   forceencryption = 1
   

   Note

   Para algumas distribuições do Linux, o caminho para armazenar o certificado e a chave também pode ser /etc/pki/tls/certs/ e /etc/pki/tls/private/ , respectivamente, . Verifique o caminho antes de atualizar o mssql.conf para contêineres do SQL Server. O local que você definir no mssql.conf é o local onde o SQL Server no contêiner vai procurar o certificado e sua chave. Nesse caso, esse local é /etc/ssl/certs/ e /etc/ssl/private/.

   O arquivo mssql.conf também é criado na mesma localização da pasta /container/sql1/. Após executar as etapas acima, você deve ter três arquivos: mssql.conf, mssql.key e mssql.pem na pasta sql1.

4. Implante o contêiner do SQL Server com o seguinte comando (substitua <password> por uma senha válida):

   docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=<password>" -p 5434:1433 --name sql1 -h sql1 -v /container/sql1/mssql.conf:/var/opt/mssql/mssql.conf -v /container/sql1/mssql.pem:/etc/ssl/certs/mssql.pem -v /container/sql1/mssql.key:/etc/ssl/private/mssql.key -d mcr.microsoft.com/mssql/server:2019-latest
   

   No comando anterior, você montou os arquivos mssql.conf, mssql.pem e mssql.key no contêiner e mapeou a porta padrão 1433 do SQL Server no contêiner para a porta 5434 no host.

   Note

   Se você usar o Red Hat Enterprise Linux 8 e versões posteriores, também poderá usar o podman run comando em vez de docker run.

Siga as seções "Registrar o certificado na sua máquina cliente" e "Exemplos de cadeias de conexão" documentadas em criptografia iniciada pelo cliente para começar a criptografar conexões para o SQL Server em Linux containers.

Conteúdo relacionado

• Implantar contêineres do SQL Server no Linux e conectar-se a eles

• Configurar e personalizar contêineres do SQL Server no Linux

• Solução de problemas de contêineres do SQL Server no Docker