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 m[blue]custodiam[][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
kcm
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.
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)
local
proxy
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)
Standard: 4
max_secrets (heltal)
Standard: 1024 (secrets-svärm), 256 (kcm-svärm)
max_uid_secrets (heltal)
Standard: 256 (secrets-svärm), 64 (kcm-svärm)
max_payload_size (heltal)
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)
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)
basic_auth
header
auth_header_name (sträng)
Exempel: MITTHEMLIGANAMN
auth_header_value (sträng)
Exempel: minhemlighet
forward_headers (lista av strängar)
Standard: inte satt
verify_peer (boolean)
Standard: true
verify_host (boolean)
Standard: true
capath (sträng)
Standard: inte satt
cacert (sträng)
Standard: inte satt
cert (sträng)
Standard: inte satt
key (sträng)
Standard: inte satt
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
Exempel:
curl -H "Content-Type: application/json" \
--unix-socket /var/run/secrets.socket \
-XGET http://localhost/secrets/
Hämta en hemlighet
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
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
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:
Radera en hemlighet eller behållare
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
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
SSSD uppströms - https://github.com/SSSD/sssd/