Partilhar via

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).

Observação

Os contêineres para SQL Server 2019 (15.x) e versões posteriores são iniciados automaticamente como não raiz, enquanto os contêineres do SQL Server 2017 (14.x) são iniciados como raiz por padrão. Para obter mais informações sobre como executar contêineres do SQL Server como não raiz, consulte Proteger contêineres do SQL Server Linux.

  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 contexto do diretório dockerfile para criar o contêiner não raiz do SQL Server:

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

  3. Inicie o recipiente.

    Importante

    A variável de ambiente SA_PASSWORD foi preterida. Use MSSQL_SA_PASSWORD em vez disso.

    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

    Observação

    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 contêiner está sendo executado como usuário 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

Advertência

Verifique se o contêiner do SQL Server tem um usuário nomeado, como mssql ou root, caso contrário, o sqlcmd não pode ser executado dentro do contêiner. Você pode verificar se o contêiner do SQL Server está sendo executado como um usuário nomeado executando whoami dentro do contêiner.

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

Você pode executar o contêiner não-raiz como o usuário raiz, se necessário, o que também concede todas as permissões de arquivo automaticamente para o contêiner, porque ele tem privilégios mais altos.

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 usuário não-root acesse arquivos de banco de dados que estão em volumes montados, certifique-se de que o usuário ou grupo no qual você executa o contêiner possa ler e gravar no armazenamento de arquivos persistente.

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

Importante

Quando você configura opções de autenticação ou criptografia do Ative Directory, como TDE (Transparent Data Encryption) e SSL/TLS para SQL Server no Linux ou contêineres, há vários arquivos, como keytab, certificados e chave da máquina, que são criados por padrão na pasta /var/opt/mssql/secretse cujo acesso é restrito por padrão para mssql e root usuários. Ao configurar o armazenamento persistente para contentores do SQL Server, use a mesma estratégia de acesso, garantindo que o caminho no host ou volume compartilhado, mapeado para a pasta /var/opt/mssql/secrets dentro do contentor, esteja protegido e acessível apenas para os utilizadores mssql e root no host também. Se o acesso a esse caminho/pasta for comprometido, um usuário mal-intencionado pode obter acesso a esses arquivos críticos, comprometendo a hierarquia de criptografia e/ou as configurações do Ative Directory.

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,port. Você também deve verificar se o caminho /container/sql1/ da pasta já existe 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 os 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 seguinte conteúdo para habilitar a criptografia iniciada pelo servidor. Para criptografia 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

    Observação

    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, montou os arquivos mssql.conf, mssql.pem e mssql.key no contentor e mapeou a porta 1433 (porta padrão do SQL Server) no contentor para a porta 5434 no anfitrião.

    Observação

    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 seções "Registrar o certificado em sua máquina cliente" e "Exemplos de cadeias de conexão" documentadas em de criptografia iniciada pelo cliente para começar a criptografar conexões com o SQL Server em contêineres Linux.

Conteúdo relacionado

  • Comece a usar as imagens de contentor do SQL Server 2017 (14.x) no Docker seguindo o guia rápido
  • Comece a usar as imagens de contentor do SQL Server 2022 (16.x) no Docker seguindo o guia de início rápido
  • Comece a usar imagens de contentores do SQL Server 2025 (17.x) no Docker passando pelo quickstart
  • Last updated on