Dela via

Säkra SQL Server Linuxbehållare

  • Artikel

gäller för:SQL Server – Linux

SQL Server 2017-containrar (14.x) startas som rotanvändare som standard, vilket kan orsaka vissa säkerhetsproblem. I den här artikeln beskrivs säkerhetsalternativ som du har när du kör SQL Server Linux-containrar och hur du skapar en SQL Server-container som en icke-rotanvändare.

Exemplen i den här artikeln förutsätter att du använder Docker, men du kan tillämpa samma principer på andra verktyg för containerorkestrering, inklusive Kubernetes.

Skapa och köra SQL Server 2017-containrar som inte är rotbaserade

Följ de här stegen för att skapa en SQL Server 2017-container (14.x) som startar som mssql-användare (icke-rot).

Not

Containrar för SQL Server 2019 (15.x) och senare versioner startas automatiskt som icke-rot, medan SQL Server 2017-containrar (14.x) startas som rot som standard. För mer information om hur du kör SQL Server-containrar som icke-root, se Secure SQL Server Linux-containrar.

  1. Ladda ned Dockerfile-exempel för SQL Server-containrar som inte är rotcontainrar och spara den som dockerfile.

  2. Kör följande kommando i kontexten för dockerfile-katalogen för att skapa en SQL Server-container som inte är rot:

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

  3. Starta containern.

    Viktig

    Miljövariabeln SA_PASSWORD är inaktuell. Använd MSSQL_SA_PASSWORD i stället.

    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

    Not

    Flaggan --cap-add SYS_PTRACE krävs för att SQL Server-containrar som inte är rot ska generera dumpar i felsökningssyfte.

  4. Kontrollera att containern körs som icke-rotanvändare:

    docker exec -it sql1 bash

    Kör whoami, som returnerar information om användaren som finns i containern.

    whoami

Kör containern som en annan icke-root användare på värdmaskinen.

Om du vill köra SQL Server-containern som en annan icke-rotanvändare lägger du till flaggan -u i kommandot docker run. Containern som inte har root-åtkomst har begränsningen att den måste köras som en del av gruppen root såvida inte en volym monteras på /var/opt/mssql som en icke-rootanvändare kan komma åt. Gruppen root beviljar inte några extra rootbehörigheter till icke-rootanvändaren.

Kör som användare med UID 4000

Du kan starta SQL Server med ett anpassat UID. Följande kommando startar till exempel SQL Server med 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

Varning

Kontrollera att SQL Server-containern har en namngiven användare, till exempel mssql eller root, annars kan sqlcmd- inte köras i containern. Du kan kontrollera om SQL Server-containern körs som en namngiven användare genom att köra whoami i containern.

Kör den icke-rotspecifika containern som rotanvändare

Du kan köra en icke-rotcontainer som rotanvändare om det behövs, vilket också automatiskt ger alla filrättigheter till containern, eftersom den har högre privilegier.

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

Kör som en användare på värddatorn

Du kan starta SQL Server med en befintlig användare på värddatorn med följande kommando:

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

Kör som en annan användare och grupp

Du kan starta SQL Server med en anpassad användare och grupp. I det här exemplet har den monterade volymen behörigheter som konfigurerats för användaren eller gruppen på värddatorn.

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

Konfigurera beständiga lagringsbehörigheter för icke-rotcontainrar

Om du vill tillåta att användaren som inte är root får åtkomst till databasfiler som ligger på monterade volymer, kontrollerar du att användaren eller gruppen som kör containern kan läsa och skriva till varaktig fillagring.

Du kan hämta det aktuella ägarskapet för databasfilerna med det här kommandot.

ls -ll <database file dir>

Kör något av följande kommandon om SQL Server inte har åtkomst till bevarade databasfiler.

Ge rotgruppen läs-/skrivåtkomst till databasfilerna

Ge root-gruppen behörighet till följande kataloger så att SQL Server-containern utan root-åtkomst har tillgång till databasfilerna.

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

Ange icke-rotanvändaren som ägare till filerna

Detta kan vara standardanvändare som inte är rotanvändare eller någon annan icke-rotanvändare som du vill ange. I det här exemplet anger vi UID 10001 som icke-rotanvändare.

chown -R 10001:0 <database file dir>

Kryptera anslutningar till SQL Server Linux-containrar

Viktig

När du konfigurerar Alternativ för Active Directory-autentisering eller kryptering, till exempel transparent datakryptering (TDE) och SSL för SQL Server i Linux eller containrar, finns det flera filer, till exempel nyckelfliken, certifikaten och datornyckeln, som skapas som standard under mappen /var/opt/mssql/secretsoch åtkomst som är begränsad som standard till mssql och root användare. När du konfigurerar beständig lagring för SQL Server-containrar använder du samma åtkomststrategi, och säkerställer att sökvägen på värden, eller den delade volymen, som mappas till /var/opt/mssql/secrets-mappen i containern, är skyddad, och endast tillgänglig för mssql- och root-användare på värden. Om åtkomsten till den här sökvägen/mappen komprometteras kan en obehörig användare få åtkomst till dessa kritiska filer, vilket äventyrar krypteringshierarkin och/eller Active Directory-konfigurationerna.

För att kryptera anslutningar till SQL Server Linux-containrar behöver du ett certifikat med följande krav.

Följande är ett exempel på hur anslutningen kan krypteras till SQL Server Linux-containrar. Här använder vi ett självsignerat certifikat som inte ska användas för produktionsscenarier. För sådana miljöer bör du använda CA-certifikat i stället.

  1. Skapa ett självsignerat certifikat som endast passar för testmiljöer och icke-produktionsmiljöer.

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

    I föregående kodexempel är sql1 värdnamnet för SQL-containern, så när du ansluter till den här containern kommer namnet som används i anslutningssträngen att vara sql1.contoso.com,port. Du måste också se till att mappsökvägen /container/sql1/ redan finns innan du kör kommandot ovan.

  2. Se till att du anger rätt behörigheter för mssql.key- och mssql.pem-filerna, så att du undviker fel när du monterar filerna i SQL Server-containern:

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

  3. Skapa nu en mssql.conf-fil med innehållet nedan för att aktivera den serverinitierade krypteringen. För Klientinitierad kryptering ändrar du den sista raden till forceencryption = 0.

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

    Notera

    För vissa Linux-distributioner kan sökvägen för att lagra certifikatet och nyckeln också vara : /etc/pki/tls/certs/ respektive /etc/pki/tls/private. Kontrollera sökvägen innan du uppdaterar mssql.conf för SQL Server-containrar. Den plats som du anger i mssql.conf är platsen där SQL Server i containern ska söka efter certifikatet och dess nyckel. I det här fallet är platsen /etc/ssl/certs/ och /etc/ssl/private/.

    Den mssql.conf filen skapas också under samma mappplats /container/sql1/. När du har kört stegen ovan bör du ha tre filer: mssql.conf, mssql.keyoch mssql.pem i mappen sql1.

  4. Distribuera SQL Server-containern med följande kommando:

    docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=P@ssw0rd" -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

    I föregående kommando har vi monterat filerna mssql.conf, mssql.pemoch mssql.key till containern och kopplat porten 1433 (SQL Server standardport) i containern till port 5434 på värden.

    Not

    Om du använder RHEL 8 och senare versioner kan du också använda kommandot podman run i stället för docker run.

Följ avsnitten "Registrera certifikatet på klientdatorn" och "Exempel på anslutningssträngar" som beskrivs i klientinitierad kryptering för att börja kryptera anslutningar till SQL Server på Linux-containrar.

Relaterat innehåll

  • Kom igång med SQL Server 2017-containeravbildningar (14.x) i Docker genom att gå igenom snabbstart
  • Kom igång med SQL Server 2019-containeravbildningar (15.x) i Docker genom att gå igenom snabbstart
  • Kom igång med SQL Server 2022-containeravbildningar (16.x) i Docker genom att gå igenom snabbstart