Proteger contêineres do SQL Server Linux

Aplica-se a:SQL Server em Linux

Os contêineres do SQL Server 2017 (14.x) são iniciados como o usuário raiz por padrão, o que pode causar alguns problemas de segurança. Este artigo fala sobre as opções de segurança que você tem ao executar contêineres Linux do SQL Server 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 pode aplicar os mesmos princípios a outras ferramentas de orquestração de contêineres, incluindo o Kubernetes.

Construir e executar contêineres sem privilégio de root do SQL Server 2017

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

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

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

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

3. Inicie o recipiente.

   Importante

   A variável de ambiente SA_PASSWORD foi preterida. Utilize MSSQL_SA_PASSWORD em substituição.

   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 indicador --cap-add SYS_PTRACE é necessário para que contentores do SQL Server sem privilégios de root gerem dumps para fins de resolução de problemas.

4. Verifique se o contentor está a correr como utilizador não root:

   docker exec -it sql1 bash
   

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

   whoami
   

Executar contêiner como um usuário não-root 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 ele deve ser executado como parte do grupo root, a menos que um volume seja montado para /var/opt/mssql que o usuário não raiz possa acessar. O grupo root não concede nenhuma permissão de root extra para o usuário não-root.

Executar como um usuário com um UID 4000

Você pode iniciar o SQL Server com um UID personalizado. 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

Execute o contenedor não-root como o utilizador root

Podes executar o contentor não-root como utilizador root, se necessário, o que também concede automaticamente todas as permissões de ficheiro ao contentor, porque tem privilégios mais elevados.

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 utilizador na sua máquina anfitriã

Você pode iniciar o SQL Server com um usuário existente na máquina 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 utilizador e grupo diferente

Você pode iniciar o SQL Server com um usuário e grupo personalizados. Neste exemplo, o volume montado tem permissões configuradas para o usuário ou grupo na máquina 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 utilizador não root aceda a ficheiros de base de dados que estejam em volumes montados, certifique-se de que o utilizador ou grupo sob o qual executa o contentor pode ler e escrever no armazenamento persistente de ficheiros.

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

ls -ll <database file dir>

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

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

Conceda permissões ao grupo raiz para os seguintes diretórios para que o contêiner não raiz do SQL Server 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-root como o proprietário dos arquivos

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

chown -R 10001:0 <database file dir>

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

Para criptografar conexões com contêineres do SQL Server Linux, você precisa de um certificado com os seguintes requisitos de .

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

1. Crie um certificado autoassinado, que é adequado apenas para ambientes de teste e 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 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 verificar se o caminho /container/sql1/ da pasta já existe antes de executar o comando anterior.

2. Certifique-se de configurar as permissões corretas nos ficheiros mssql.key e mssql.pem, para evitar erros ao montar os ficheiros no contentor do SQL Server:

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

3. Agora crie um mssql.conf ficheiro com o seguinte conteúdo para ativar a encriptação iniciada pelo servidor. Para encriptação iniciada pelo cliente, altere 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 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 definido no mssql.conf é o local onde o SQL Server no contêiner vai procurar o certificado e sua chave. Neste caso, esse local é /etc/ssl/certs/ e /etc/ssl/private/.

   O arquivo mssql.conf também é criado no mesmo local de pasta /container/sql1/. Depois de executar as etapas acima, você deve ter três arquivos: mssql.conf, mssql.keye 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, montaste os ficheiros mssql.conf, mssql.pem e mssql.key no contentor e mapeaste a porta predefinida 1433 do SQL Server no contentor para a porta 5434 no anfitrião.

   Note

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

Siga as secções "Registar o certificado na sua máquina cliente" e "Exemplos de cadeias de ligação" documentadas na encriptação iniciada pelo cliente para começar a encriptar ligações ao SQL Server em Linux containers.

Conteúdo relacionado

• Implantar e conectar-se a contentores do SQL Server no Linux

• Configurar e personalizar contêineres do SQL Server Linux

• Solucionar problemas de contêineres do SQL Server Docker