'\" t
.\"     Title: sssd-secrets
.\"    Author: The SSSD upstream - https://pagure.io/SSSD/sssd/
.\" Generator: DocBook XSL Stylesheets v1.79.1 <http://docbook.sf.net/>
.\"      Date: 02/24/2019
.\"    Manual: File Formats and Conventions
.\"    Source: SSSD
.\"  Language: English
.\"
.TH "SSSD\-SECRETS" "5" "02/24/2019" "SSSD" "File Formats and Conventions"
.\" -----------------------------------------------------------------
.\" * Define some portability stuff
.\" -----------------------------------------------------------------
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.\" http://bugs.debian.org/507673
.\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.ie \n(.g .ds Aq \(aq
.el       .ds Aq '
.\" -----------------------------------------------------------------
.\" * set default formatting
.\" -----------------------------------------------------------------
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
.ad l
.\" -----------------------------------------------------------------
.\" * MAIN CONTENT STARTS HERE *
.\" -----------------------------------------------------------------
.SH "NAME"
sssd-secrets \- SSSD Secrets responder
.SH "DESCRIPTION"
.PP
This manual page describes the configuration of the Secrets responder for
\fBsssd\fR(8)\&. For a detailed syntax reference, refer to the
\(lqFILE FORMAT\(rq
section of the
\fBsssd.conf\fR(5)
manual page\&.
.PP
Many system and user applications need to store private information such as passwords or service keys and have no good way to properly deal with them\&. The simple approach is to embed these
\(lqsecrets\(rq
into configuration files potentially ending up exposing sensitive key material to backups, config management system and in general making it harder to secure data\&.
.PP
The
\m[blue]\fBcustodia\fR\m[]\&\s-2\u[1]\d\s+2
project was born to deal with this problem in cloud like environments, but we found the idea compelling even at a single system level\&. As a security service, SSSD is ideal to host this capability while offering the same API via a UNIX Socket\&. This will make it possible to use local calls and have them transparently routed to a local or a remote key management store like IPA Vault for storage, escrow and recovery\&.
.PP
The secrets are simple key\-value pairs\&. Each user\*(Aqs secrets are namespaced using their user ID, which means the secrets will never collide between users\&. Secrets can be stored inside
\(lqcontainers\(rq
which can be nested\&.
.PP
Since the secrets responder can be used both externally to store general secrets, as described in the rest of this man page, but also internally by other SSSD components to store their secret material, some configuration options, like quotas can be configured per
\(lqhive\(rq
in a configuration subsection named after the hive\&. The currently supported hives are:
.PP
secrets
.RS 4
secrets for general usage
.RE
.PP
kcm
.RS 4
used by the
\fBsssd-kcm\fR(8)
service\&.
.RE
.SH "USING THE SECRETS RESPONDER"
.PP
The UNIX socket the SSSD responder listens on is located at
/var/run/secrets\&.socket\&.
.PP
The secrets responder is socket\-activated by
\fBsystemd\fR(1)\&. Unlike other SSSD responders, it cannot be started by adding the
\(lqsecrets\(rq
string to the
\(lqservice\(rq
directive\&. The systemd socket unit is called
\(lqsssd\-secrets\&.socket\(rq
and the corresponding service file is called
\(lqsssd\-secrets\&.service\(rq\&. In order for the service to be socket\-activated, make sure the socket is enabled and active and the service is enabled:
.sp
.if n \{\
.RS 4
.\}
.nf
systemctl start sssd\-secrets\&.socket
systemctl enable sssd\-secrets\&.socket
systemctl enable sssd\-secrets\&.service
            
.fi
.if n \{\
.RE
.\}
.sp
Please note your distribution may already configure the units for you\&.
.SH "CONFIGURATION OPTIONS"
.PP
The generic SSSD responder options such as
\(lqdebug_level\(rq
or
\(lqfd_limit\(rq
are accepted by the secrets responder\&. Please refer to the
\fBsssd.conf\fR(5)
manual page for a complete list\&. In addition, there are some secrets\-specific options as well\&.
.PP
The secrets responder is configured with a global
\(lq[secrets]\(rq
section and an optional per\-user
\(lq[secrets/users/$uid]\(rq
section in
sssd\&.conf\&. Please note that some options, notably as the provider type, can only be specified in the per\-user subsections\&.
.PP
provider (string)
.RS 4
This option specifies where should the secrets be stored\&. The secrets responder can configure a per\-user subsections (e\&.g\&.
\(lq[secrets/users/123]\(rq
\- see bottom of this manual page for a full example using Custodia for a particular user) that define which provider store the secrets for this particular user\&. The per\-user subsections should contain all options for that user\*(Aqs provider\&. Please note that currently the global provider is always local, the proxy provider can only be specified in a per\-user section\&. The following providers are supported:
.PP
local
.RS 4
The secrets are stored in a local database, encrypted at rest with a master key\&. The local provider does not have any additional config options at the moment\&.
.RE
.PP
proxy
.RS 4
The secrets responder forwards the requests to a Custodia server\&. The proxy provider supports several additional options (see below)\&.
.RE
.sp
Default: local
.RE
.PP
The following options affect only the secrets
\(lqhive\(rq
and therefore should be set in a per\-hive subsection\&. Setting the option to 0 means "unlimited"\&.
.PP
containers_nest_level (integer)
.RS 4
This option specifies the maximum allowed number of nested containers\&.
.sp
Default: 4
.RE
.PP
max_secrets (integer)
.RS 4
This option specifies the maximum number of secrets that can be stored in the hive\&.
.sp
Default: 1024 (secrets hive), 256 (kcm hive)
.RE
.PP
max_uid_secrets (integer)
.RS 4
This option specifies the maximum number of secrets that can be stored per\-UID in the hive\&.
.sp
Default: 256 (secrets hive), 64 (kcm hive)
.RE
.PP
max_payload_size (integer)
.RS 4
This option specifies the maximum payload size allowed for a secret payload in kilobytes\&.
.sp
Default: 16 (secrets hive), 65536 (64 MiB) (kcm hive)
.RE
.PP
For example, to adjust quotas differently for both the
\(lqsecrets\(rq
and the
\(lqkcm\(rq
hives, configure the following:
.sp
.if n \{\
.RS 4
.\}
.nf
[secrets/secrets]
max_payload_size = 128

[secrets/kcm]
max_payload_size = 256
            
.fi
.if n \{\
.RE
.\}
.PP
The following options are only applicable for configurations that use the
\(lqproxy\(rq
provider\&.
.PP
proxy_url (string)
.RS 4
The URL the Custodia server is listening on\&. At the moment, http and https protocols are supported\&.
.sp
The format of the URI must match the format defined in RFC 2732:
.sp
http[s]://<host>[:port]
.sp
Example: http://localhost:8080
.RE
.PP
auth_type (string)
.RS 4
The method to use when authenticating to a Custodia server\&. The following authentication methods are supported:
.PP
basic_auth
.RS 4
Authenticate with a username and a password as set in the
\(lqusername\(rq
and
\(lqpassword\(rq
options\&.
.RE
.PP
header
.RS 4
Authenticate with HTTP header value as defined in the
\(lqauth_header_name\(rq
and
\(lqauth_header_value\(rq
configuration options\&.
.RE
.RE
.PP
auth_header_name (string)
.RS 4
If set, the secrets responder would put a header with this name into the HTTP request with the value defined in the
\(lqauth_header_value\(rq
configuration option\&.
.sp
Example: MYSECRETNAME
.RE
.PP
auth_header_value (string)
.RS 4
The value sssd\-secrets would use for the
\(lqauth_header_name\(rq\&.
.sp
Example: mysecret
.RE
.PP
forward_headers (list of strings)
.RS 4
The list of HTTP headers to forward to the Custodia server together with the request\&.
.sp
Default: not set
.RE
.PP
verify_peer (boolean)
.RS 4
Whether peer\*(Aqs certificate should be verified and valid if HTTPS protocol is used with the proxy provider\&.
.sp
Default: true
.RE
.PP
verify_host (boolean)
.RS 4
Whether peer\*(Aqs hostname must match with hostname in its certificate if HTTPS protocol is used with the proxy provider\&.
.sp
Default: true
.RE
.PP
capath (string)
.RS 4
Path to directory containing stored certificate authority certificates\&. System default path is used if this option is not set\&.
.sp
Default: not set
.RE
.PP
cacert (string)
.RS 4
Path to file containing server\*(Aqs certificate authority certificate\&. If this option is not set then the CA\*(Aqs certificate is looked up in
\(lqcapath\(rq\&.
.sp
Default: not set
.RE
.PP
cert (string)
.RS 4
Path to file containing client\*(Aqs certificate if required by the server\&. This file may also contain private key or the private key may be in separate file set with
\(lqkey\(rq\&.
.sp
Default: not set
.RE
.PP
key (string)
.RS 4
Path to file containing client\*(Aqs private key\&.
.sp
Default: not set
.RE
.SH "USING THE REST API"
.PP
This section lists the available commands and includes examples using the
\fBcurl\fR(1)
utility\&. All requests towards the proxy provider must set the Content Type header to
\(lqapplication/json\(rq\&. In addition, the local provider also supports Content Type set to
\(lqapplication/octet\-stream\(rq\&. Secrets stored with requests that set the Content Type header to
\(lqapplication/octet\-stream\(rq
are base64\-encoded when stored and decoded when retrieved, so it\*(Aqs not possible to store a secret with one Content Type and retrieve with another\&. The secret URI must begin with
/secrets/\&.
.PP
Listing secrets
.RS 4
To list the available secrets, send a HTTP GET request with a trailing slash appended to the container path\&.
.sp
Example:
.sp
.if n \{\
.RS 4
.\}
.nf
curl \-H "Content\-Type: application/json" \e
     \-\-unix\-socket /var/run/secrets\&.socket \e
     \-XGET http://localhost/secrets/
                        
.fi
.if n \{\
.RE
.\}
.sp
.RE
.PP
Retrieving a secret
.RS 4
To read a value of a single secret, send a HTTP GET request without a trailing slash\&. The last portion of the URI is the name of the secret\&.
.sp
Examples:
.sp
.if n \{\
.RS 4
.\}
.nf
curl \-H "Content\-Type: application/json" \e
     \-\-unix\-socket /var/run/secrets\&.socket \e
     \-XGET http://localhost/secrets/foo
                        
.fi
.if n \{\
.RE
.\}
.sp

.sp
.if n \{\
.RS 4
.\}
.nf
curl \-H "Content\-Type: application/octet\-stream" \e
     \-\-unix\-socket /var/run/secrets\&.socket \e
     \-XGET http://localhost/secrets/bar
                        
.fi
.if n \{\
.RE
.\}
.sp
.RE
.PP
Setting a secret
.RS 4
To set a secret using the
\(lqapplication/json\(rq
type, send a HTTP PUT request with a JSON payload that includes type and value\&. The type should be set to "simple" and the value should be set to the secret value\&. If a secret with that name already exists, the response is a 409 HTTP error\&.
.sp
The
\(lqapplication/json\(rq
type just sends the secret as the message payload\&.
.sp
The following example sets a secret named \*(Aqfoo\*(Aq to a value of \*(Aqfoosecret\*(Aq and a secret named \*(Aqbar\*(Aq to a value of \*(Aqbarsecret\*(Aq using a different Content Type\&.
.sp
.if n \{\
.RS 4
.\}
.nf
curl \-H "Content\-Type: application/json" \e
     \-\-unix\-socket /var/run/secrets\&.socket \e
     \-XPUT http://localhost/secrets/foo \e
     \-d\*(Aq{"type":"simple","value":"foosecret"}\*(Aq
                        
.fi
.if n \{\
.RE
.\}
.sp

.sp
.if n \{\
.RS 4
.\}
.nf
curl \-H "Content\-Type: application/octet\-stream" \e
     \-\-unix\-socket /var/run/secrets\&.socket \e
     \-XPUT http://localhost/secrets/bar \e
     \-d\*(Aqbarsecret\*(Aq
                        
.fi
.if n \{\
.RE
.\}
.sp
.RE
.PP
Creating a container
.RS 4
Containers provide an additional namespace for this user\*(Aqs secrets\&. To create a container, send a HTTP POST request, whose URI ends with the container name\&. Please note the URI must end with a trailing slash\&.
.sp
The following example creates a container named \*(Aqmycontainer\*(Aq:
.sp
.if n \{\
.RS 4
.\}
.nf
curl \-H "Content\-Type: application/json" \e
     \-\-unix\-socket /var/run/secrets\&.socket \e
     \-XPOST http://localhost/secrets/mycontainer/
                        
.fi
.if n \{\
.RE
.\}
.sp
To manipulate secrets under this container, just nest the secrets underneath the container path:
.sp
.if n \{\
.RS 4
.\}
.nf
http://localhost/secrets/mycontainer/mysecret
                        
.fi
.if n \{\
.RE
.\}
.sp
.RE
.PP
Deleting a secret or a container
.RS 4
To delete a secret or a container, send a HTTP DELETE request with a path to the secret or the container\&.
.sp
The following example deletes a secret named \*(Aqfoo\*(Aq\&.
.sp
.if n \{\
.RS 4
.\}
.nf
curl \-H "Content\-Type: application/json" \e
     \-\-unix\-socket /var/run/secrets\&.socket \e
     \-XDELETE http://localhost/secrets/foo
                        
.fi
.if n \{\
.RE
.\}
.sp
.RE
.SH "EXAMPLE CUSTODIA AND PROXY PROVIDER CONFIGURATION"
.PP
For testing the proxy provider, you need to set up a Custodia server to proxy requests to\&. Please always consult the Custodia documentation, the configuration directives might change with different Custodia versions\&.
.PP
This configuration will set up a Custodia server listening on http://localhost:8080, allowing anyone with header named MYSECRETNAME set to mysecretkey to communicate with the Custodia server\&. Place the contents into a file (for example,
\fIcustodia\&.conf\fR):
.sp
.if n \{\
.RS 4
.\}
.nf
[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 = MYSECRETNAME
value = mysecretkey

[authz:paths]
handler = custodia\&.httpd\&.authorizers\&.SimplePathAuthz
paths = /secrets

[/]
handler = custodia\&.root\&.Root
store = simple
            
.fi
.if n \{\
.RE
.\}
.PP
Then run the
\fIcustodia\fR
command, pointing it at the config file as a command line argument\&.
.PP
Please note that currently it\*(Aqs not possible to proxy all requests globally to a Custodia instance\&. Instead, per\-user subsections for user IDs that should proxy requests to Custodia must be defined\&. The following example illustrates a configuration, where the user with UID 123 would proxy their requests to Custodia, but all other user\*(Aqs requests would be handled by a local provider\&.
.sp
.if n \{\
.RS 4
.\}
.nf
[secrets]

[secrets/users/123]
provider = proxy
proxy_url = http://localhost:8080/secrets/
auth_type = header
auth_header_name = MYSECRETNAME
auth_header_value = mysecretkey
        
.fi
.if n \{\
.RE
.\}
.SH "AUTHORS"
.PP
\fBThe SSSD upstream \- https://pagure\&.io/SSSD/sssd/\fR
.SH "NOTES"
.IP " 1." 4
custodia
.RS 4
\%https://github.com/latchset/custodia
.RE