SSSD-SECRETS(5)

NAME
sssd-secrets - SSSD Secrets-respondent

BESKRIVNING

Denna manualsida beskriver konfigurationen av Secrets-respondenten till sssd(8). För en detaljerad referens om syntaxen, se avsnittet “FILFORMAT” i manualsidan sssd.conf(5).

Många system och användarprogram behöver lagra privat information såsom lösenord eller tjänstenycklar och har inget bra sätt att ta hand om dem ordentligt. Den enkla vägen är att bädda in dessa “hemligheter” i konfigurationsfiler där de potentiellt kan komma att exponera känslig nyckelinformation till säkerhetskopior, konfigurationshanteringssystem och gör det i allmänhet svårare att säkra datan.

Projektet custodia[1] föddes för att ta hand om detta problem i molnlika miljöer, men vi tyckte att idén var övertygande även på nivån av enstaka system. Som en säkerhetstjänst är SSSD ideal för att hantera denna funktionalitet och samtidigt erbjuda samma API via ett UNIX-uttag. Detta kommer göra det möjligt att använda lokala anrop och få dem dirigerade transparent till ett lokalt eller fjärran nyckelhanteringslager såsom IPA Vault för lagring, deponering och återhämtning.

Hemligheterna är enkla nyckel-värde-par. Varje användares hemligheter ligger i en namnrymd efter deras användar-ID, vilket betyder att hemligheter aldrig kommer kollidera mellan användare. Hemligheter kan lagras inuti “behållare” som kan nästas.

Eftersom secrets-respondenten kan användas både externt för att lagra allmänna hemligheter, såsom beskrives i resten av den här manualsidan, men också internt av andra SSSD-komponenter för att lagra deras material kan några konfigurationsalternativ, som kvoter konfigureras per “svärm” i ett konfigurationsavsnitt namngivet efter svärmen. De svärmar som stödjs för närvarande är:

secrets
    hemligheter för allmän användning

kcm
    används av tjänsten sssd-kcm(8).

ANVÄNDA SECRETS-RESPONDENTEN

UNIX-uttaget SSSD-respondenten lyssnar på finns på /var/run/secrets.socket.

Secrets-respondenten är uttagsaktiverad av systemd(1). Till skillnad mot andra SSSD-respondenter, kan den inte startas genom att lägga till strängen “secrets” till direktivet “service”. Systemd-uttagsenheten heter “sssd-secrets.socket” och den motsvarande tjänstefilen heter “sssd-secrets.service”. För att tjänsten skall vara uttagsaktiverad, se till att uttaget är aktiverat och aktivt och att tjänsten är aktiverad:

    systemctl start sssd-secrets.socket
    systemctl enable sssd-secrets.socket
    systemctl enable sssd-secrets.service

Observera att din distribution redan kan ha konfigurerat enheterna åt dig.

KONFIGURATIONSALTERNATIV

De allmänna alternativen för SSSD-respondenter såsom “debug_level” eller “fd_limit” accepteras av secrets-respondenten. Se manualsidan sssd.conf(5) för en fullständig lista. Dessutom finns det några secrets-specifika alternativ också.

Secrets-respondenten är konfigurerad i ett globalt avsnitt “[secrets]” och ett valfritt avsnitt per användare “[secrets/users/$uid]” i sssd.conf. Observera att några alternativ, speciellt leverantörstypen, bara kan anges i underavsnitt per användare.

provider (sträng)
    Alternativet anger var hemligheterna skall sparas. Secrets-respondenten kan konfigurera ett underavsnitt per användare (t.ex. “[secrets/users/123]” – se slutet av denna manualsida för ett fullständigt exempel som använder Custodia för en viss användare) som definierar vilken leverantör som sparar hemligheterna för denna specifika användare. Underavsnittet per användare skall innehålla alla alternativ för den användarens leverantör. Observera att för närvarande är alltid den globala leverantören lokal, proxy-leverantören kan endast anges i ett avsnitt per användare. Följande leverantörer stödjs:

    local
        Hemligheterna sparas i en lokal databas, krypterad i vila med en huvudnyckel. Den lokala leverantören har inte några ytterligare konfigurationsalternativ för tillfället.

    proxy
        Secrets-respondenten vidarebefordrar begäranden till en Custodia-server. Proxy-leverantören stödjer flera ytterligare alternativ (se nedan).

    Standard: local

Följande alternativ påverkar endast hemlighets-“svärmen” och skall därför sättas i ett underavsnitt per svärm. Att sätta alternativet till 0 betyder ”obegränsat”.

containers_nest_level (heltal)
    Detta alternativ specificerar det maximala antalet tillåtna nästade behållare.

    Standard: 4

max_secrets (heltal)
    Detta alternativ anger det maximala antalet hemligheter som kan sparas i svärmen.

    Standard: 1024 (secrets-svärm), 256 (kcm-svärm)

max_uid_secrets (heltal)
    Detta alternativ anger det maximala antalet hemligheter som kan sparas per AID i svärmen.

    Standard: 256 (secrets-svärm), 64 (kcm-svärm)

max_payload_size (heltal)
    Detta alternativ anger den maximala laststorleken som tillåts för en hemlighetslast i kilobyte.

    Standard: 16 (secrets-svärm), 65536 (64 MiB) (kcm-svärm)

Till exempel, för att justera kvoter olika för både svärmen “secrets” och “kcm”, konfigurera följande:

    [secrets/secrets]
    max_payload_size = 128
    [secrets/kcm]
    max_payload_size = 256

Följande alternativ är endast användbara för konfigurationer som använder leverantören “proxy”.

proxy_url (sträng)
    URL:en Custodia-servern lyssnar på. För tillfället stödjs protokollen http och https.

    Formatet på URI:n måste stämma med formatet som definieras i RFC 2732:

    http[s]://<värd>[:port]

    Exempel: http://localhost:8080

auth_type (sträng)
    Metoden att använda vid autentisering mot en Custodia-server. Följande autentiseringsmetoder stödjs:

    basic_auth
        Autentisera med ett användarnamn och lösenord som satts i alternativen “username” och “password”.

    header
        Autentisera med ett HTTP-huvudvärde som det är definierat i konfigurationsalternativen “auth_header_name” och “auth_header_value”.

auth_header_name (sträng)
    Om satt kommer secrets-respondenten lägga in ett huvud med detta namn i HTTP-begäranden med värdet som definieras i konfigurationsalternativet “auth_header_value”.

    Exempel: MITTHEMLIGANAMN

auth_header_value (sträng)
    Värdet sssd-secrets kommer använda till “auth_header_name”.

    Exempel: minhemlighet

forward_headers (lista av strängar)
    Listan över HTTP-huvuden att vidarebefordra till Custodia-servern tillsammans med begäran.

    Standard: inte satt

verify_peer (boolean)
    Huruvida motpartens certifikat skall verifieras och vara giltigt om HTTPS-protokollet används med proxy-leverantören.

    Standard: true

verify_host (boolean)
    Huruvida motpartens värdnamn måste stämma med värdnamnet i dess certifikat om HTTPS-protokollet används med proxy-leverantören.

    Standard: true

capath (sträng)
    Sökväg till katalogen som innehåller lagrade certifikatutfärdares certifikat. Systemets standardsökväg används om detta alternativ inte är satt.

    Standard: inte satt

cacert (sträng)
    Sökväg till filen som innehåller serverns certifikatauktoritetscertifikat. Om detta alternativ inte är satt, då slås CA:ns certifikat upp i “capath”.

    Standard: inte satt

cert (sträng)
    Sökväg till filen som innehåller klientens certifikat om det krävs av servern. Denna fil kan också innehålla en privat nyckel eller så kan den privata nyckeln finnas i en separat fil som anges med “key”.

    Standard: inte satt

key (sträng)
    Sökväg till filen som innehåller klientens privata nyckel.

    Standard: inte satt

ATT ANVÄNDA REST-API:ET

Detta avsnitt listar tillgängliga kommandon och inkluderar exempel som använder verktyget curl(1). Alla begäranden av proxy-leverantören måste sätta huvudet Content Type till “application/json”. Dessutom stödjer den lokala leverantören även att Content Type sätts till “application/octet-stream”. Hemligheter sparade med begäranden som sätter huvudet Content Type till “application/octet-stream” base64-kodas när de lagras och avkodas när de hämtas, så det är inte möjligt att lagra en hemlighet med en Content Type och hämta med en annan. URI:n för hemligheter måste börja med /secrets/.

Lista hemligheter
    För att lista de tillgängliga hemligheterna, skicka en HTTP GET-begäran med ett avslutande snedstreck tillagt på behållarsökvägen.

    Exempel:

        curl -H "Content-Type: application/json" \
             --unix-socket /var/run/secrets.socket \
             -XGET http://localhost/secrets/

Hämta en hemlighet
    För att läsa värdet på en enskild hemlighet, skicka en HTTP GET-begäran utan ett avslutande snedstreck. Den sista delen av URI:n är namnet på hemligheten.

    Exempel:

        curl -H "Content-Type: application/json" \
             --unix-socket /var/run/secrets.socket \
             -XGET http://localhost/secrets/apa

        curl -H "Content-Type: application/octet-stream" \
             --unix-socket /var/run/secrets.socket \
             -XGET http://localhost/secrets/bepa

Spara en hemlighet
    För att spara en hemlighet med typen “application/json”, skicka en HTTP PUT-begäran med en JSON-last som innehåller typ och värde. Typen skall sättas till ”simple” och värdet skall sättas till hemlighetens värde. Om en hemlighet med det namnet redan finns blir svaret ett 409 HTTP-fel.

    Typen “application/json” skickar bara hemligheten som meddelandets last.

    Följande exempel sparar en hemlighet som heter ”apa” till värdet ”hemligapa” och en hemlighet som heter ”bepa” till värdet ”hemligbepa” genom att använda en annan Content Type.

        curl -H "Content-Type: application/json" \
             --unix-socket /var/run/secrets.socket \
             -XPUT http://localhost/secrets/apa \
             -d'{"type":"simple","value":"hemligapa"}'

        curl -H "Content-Type: application/octet-stream" \
             --unix-socket /var/run/secrets.socket \
             -XPUT http://localhost/secrets/bepa \
             -d'hemligbepa'

Att skapa en behållare
    Behållare tillhandahåller en ytterligare namnrymd för denna användares hemligheter. För att skapa en behållare, skicka en HTTP POST-begäran, vars URI slutar med behållarnamnet. Observera att URI:n måste sluta med ett avslutande snedstreck.

    Följande exempel skapar en behållare som heter ”minbehållare”:

        curl -H "Content-Type: application/json" \
             --unix-socket /var/run/secrets.socket \
             -XPOST http://localhost/secrets/minbeh%C3%A5llare/

    För att hantera hemligheter under den här behållaren, nästa bara hemligheter under behållarsökvägen:

        http://localhost/secrets/minbeh%C3%A5llare/minhemlighet

Radera en hemlighet eller behållare
    För att radera en hemlighet eller behållare, skicka en HTTP DELETE-begäran med en sökväg till hemligheten eller behållaren.

    Följande exempel raderar en hemlighet som heter ”apa”:

        curl -H "Content-Type: application/json" \
             --unix-socket /var/run/secrets.socket \
             -XDELETE http://localhost/secrets/apa

EXEMPEL PÅ KONFIGURATION AV CUSTODIA- OCH PROXY-LEVERANTÖRER

För att testa proxy-leverantören behöver du sätta upp en Custodia-server att vidarebefordra begäranden till. Se till att läsa dokumentationen till Custodia, konfigurationsdirektiven kan ändras med olika Custodia-versioner.

Denna konfiguration kommer sätta upp en Custodia-server som lyssnar på http://localhost:8080, tillåter vem som helst med ett huvud med namnet MITTHEMLIGANAMN satt till minhemliganyckel att kommunicera med Custodia-servern. Placera innehållet i en fil (till exempel, custodia.conf):

    [global]
    server_version = "Secret/0.0.7"
    server_url = http://localhost:8080/
    auditlog = /var/log/custodia.log
    debug = True
    [store:simple]
    handler = custodia.store.sqlite.SqliteStore
    dburi = /var/lib/custodia.db
    table = secrets
    [auth:header]
    handler = custodia.httpd.authenticators.SimpleHeaderAuth
    header = MITTHEMLIGANAMN
    value = minhemliganyckel
    [authz:paths]
    handler = custodia.httpd.authorizers.SimplePathAuthz
    paths = /secrets
    [/]
    handler = custodia.root.Root
    store = simple

Kör sedan kommandot custodia och peka det på konfigurationsfilen som ett kommandoradsargument.

Observera att det för närvarande inte är möjligt att vidarebefordra alla begäranden globalt till en Custodia-instans. Istället måste underavsnitt per användare för användar-ID:n som skall skicka vidare begäranden till Custodia definieras. Följande exempel illustrerar en konfiguration där användaren med AID 123 skulle skicka vidare sina begäranden till Custodia, men alla andra användares begäranden skulle hanteras av en lokal leverantör.

    [secrets]
    [secrets/users/123]
    provider = proxy
    proxy_url = http://localhost:8080/secrets/
    auth_type = header
    auth_header_name = MITTHEMLIGANAMN
    auth_header_value = minhemliganyckel

AUTHORS

SSSD uppströms – https://github.com/SSSD/sssd/

NOTES

1.  custodia
    https://github.com/latchset/custodia