Management servers

You can configure the following management servers on the SR Linux:

gNMI server – allows external gNMI clients to connect to the device and modify the configuration and collect state information
JSON-RPC server – allows you to issue JSON-formatted requests to the device to retrieve and set configuration and state

You can configure Transport Layer Security (TLS) profiles, which contain TLS settings that can be provided to the gNMI and JSON-RPC management servers.

gNMI server

The SR Linux device can enable a gNMI server that allows external gNMI clients to connect to the device and modify the configuration and collect state information.

When the gNMI server is enabled, the SR Linux gnmi_mgr application functions as a target for gNMI clients. The gnmi_mgr application validates gNMI clients and passes Get, Set, and Subscribe RPCs to the SR Linux mgmt_svr application via the gRPC interface. See the SR Linux System Management Guide for details about the supported RPCs.

Configuration changes made by gNMI clients are made within a private candidate configuration, using a snapshot of the current running configuration as a baseline for the private candidate. As with other types of candidate configurations, the private candidate can operate in exclusive mode, which locks out other users from concurrently modifying the private candidate configuration.

Sessions between gNMI clients and the SR Linux device must be encrypted using TLS. You can specify TLS settings within a TLS profile, and apply the TLS profile when configuring a gNMI server within a network-instance. When the gNMI server is enabled, gNMI clients connect and authenticate to the SR Linux device using the settings specified in the TLS profile.

New connections between gNMI clients and the SR Linux device are mutually authenticated. By default, the SR Linux device validates the X.509 certificate of the gNMI client, and the other way around; this behavior can be disabled in the TLS profile. The SR Linux device, after validating the X.509 certificate of the gNMI client, performs local authentication, if the use-authentication parameter is set to true. In this case, the gNMI client is required to provide a username and password in the metadata of the Get, Set, and Subscribe RPCs. The supplied username and password are authenticated by the SR Linux aaa_mgr application.

In cases where the client's X.509 certificate contains a SPIFFE-ID, the SPIFFE- ID is checked for a match with any user in the system. When a match is found, the client receives the permissions granted to that user. The user is rejected if there is no match. For information about using SPIFFE for client authentication, see Using SPIFFE for client authentication (mTLS).

See the SR Linux System Management Guide for examples of using the gnmi_cli, gnmi_get, and gnmi_set open source gNMI clients to configure and retrieve state information about the SR Linux device.

Configuring a gNMI server

The SR Linux supports configuring a gNMI server under one or more network-instances. You can specify limits for the number of simultaneous active gNMI client sessions, as well as the number of connection attempts per minute by gNMI clients.

For the network-instance where the gNMI server is running, you can specify the IP address and port for gNMI client connections, as well as the TLS profile used for authenticating gNMI clients. See TLS profiles.

The following example shows a configuration that enables a gNMI server on the SR Linux device. The gNMI server is configured so that gNMI clients can connect to the SR Linux via the mgmt network-instance on port 50052. Connecting gNMI clients are authenticated using the settings specified in the TLS profile tls-profile-1.

--{ * candidate shared default }--[  ]--
# info system gnmi-server
    system {
        gnmi-server {
            admin-state enable
            timeout 7200
            rate-limit 60
            session-limit 20
            network-instance mgmt {
                admin-state enable
                use-authentication true
                port 50052
                tls-profile tls-profile-1
                source-address [
                    ::
                ]
            }
        }
 }

JSON-RPC server

You can enable a JSON-RPC server on the SR Linux device, which allows you to issue JSON-formatted requests to the device to retrieve and set configuration and state. You can use the JSON-RPC API to run CLI commands and standard get and set methods. The SR Linux device returns responses in JSON-format.

Configuration changes made using the JSON-RPC API are made within a private candidate configuration, using a snapshot of the current running configuration as a baseline for the private candidate. As with other types of candidate configurations, the private candidate can operate in exclusive mode, which locks out other users from concurrently modifying the private candidate configuration.

When the JSON-RPC server is enabled, the application passes the requests to the SR Linux mgmt_svr application via the gRPC interface. This JSON-RPC API uses HTTP and HTTPS for transport and users are authenticated with the aaa_mgr application. HTTPS requests can be authenticated using TLS, using settings specified in a TLS profile. See TLS profiles.

See the SR Linux System Management Guide for examples of using the get method to retrieve state information from the SR Linux, the set method to modify the SR Linux configuration, and the cli method to enter SR Linux CLI commands.

Configuring a JSON-RPC server

The SR Linux supports configuring a JSON-RPC server under one or more network-instances. You can specify limits for the number of simultaneous active HTTP or HTTPS connections and the TCP port used for HTTP or HTTPS connections. If the TCP port is in use when the JSON-RPC server attempts to bind to it, the commit operation fails.

The following example shows a configuration that enables a JSON-RPC server within the mgmt network-instance on the SR Linux device. The JSON-RPC server is configured so that HTTP requests are accepted on TCP port 4000and TCP port 443. HTTPS requests are authenticated using the settings in the TLS profile tls-profile-1.

--{ * candidate shared default }--[  ]--
# info system json-rpc-server  
    system {
        json-rpc-server {
            admin-state enable {
            network-instance mgmt {
                http {
                    admin-state enable
                    use-authentication true
                    session-limit 1
                    port 4000
                }
                https {
                    admin-state enable
                    use-authentication true
                    session-limit 1
                    port 443
                    tls-profile tls-profile-1
                source-address [
                    ::
                ]
                }
        }
    }

Note:

To connect to the configured JSON-RPC server, enter the <source-address> defined in the system json-rpc-server configuration, followed by /jsonrpc:

https(s)://<source-address>/jsonrpc

TLS profiles

TLS is a protocol for enabling applications or devices to exchange information. The SR Linux supports configuring TLS settings in TLS profiles, which can be provided to applications such as the gNMI server and the JSON-RPC server, so that clients connecting to the SR Linux device via these applications are authenticated using the settings in the TLS profile.

Configuring a TLS profile

A TLS profile can specify whether authentication is performed for clients connecting to SR Linux applications to which the profile is applied. Within a TLS profile, you can configure certificates, keys, and ciphers to use when negotiating TLS connections with clients.

--{ * candidate shared default }--[  ]--
# info system tls
    system {
        tls {
            server-profile tls-profile-1 {
                   key $aes$4NAaR4Zz5skA=$3Pv773cUer0TaPNHqRQ==
                   certificate "-----BEGIN CERTIFICATE-----
MIIEUjCCAjoCAQAwDTELMAkGA1UEBhMCVVMwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDxG7nZ
qw7EjHM6uBit7Bi1gO/PgQTD2OqJTOtFqEXcFzGcbeeFk903v7OTNws0h11A1pZGnT9fPXv/
hYmAcvOv4FZz99jrGZ8WiwJMpxG+wG3rNdCwEfc59cqFOu9k8pbxLZVYck+pVcjgUK9wLZMHtDVYADXp7I5h
NYMLdettpSSucXaZcWpTzD/xJtePa9dkQ75LGcl/
JMivhx+7EYsbBRlkoSeluMByGavxjefNPJFtvOUAPE7CvdMprntHA7op5FkSoqZcoTzA0V1BcaNtblU7j8DL
1UnsRk6Mi9M5Sz5McQDW8cn223pT9AceLCM27LY62rNEcpAZHNumPqG352+mdLqZ7sJmfwScB3EISj6YV+ni
sZ+K8woR7PD0oz3rsnYGjjtE3xf/
NwXNdioFaVF80nkhwbpoSYZFuwzigkBvsyeUQzmYe4ehC5eFezmWracItmsqzjsDqoJZa5y3ngAK72ag9wQN
2Lz3AHYvMlC3Gn4D2P/
oNH1ywL0DeSdEMxukQamSF8EiEvCu1cBkBhab3blVOp61c7IsaNHdW1k95cFpfNLT+1HoWJlkaIVI7gCTgPW
2UURy67lUBAl4rdpFnnkRLnJfKYgjScLWSw0ur17NOTinflAgx4k5AXZP8FpvW3S0KyqR0S8UHajcsYsRd7W
aIVOhFOeXUxYeGQIDAQABoAAwDQYJKoZIhvcNAQELBQADggIBAFdyqd7yGmbM9E12i4y7nwUvORg5nwr6b5Z
aCGnCl3h8bYerhS/QjNTahAJYKl+G2pYCOdfq435B8NNFdsEfBJ9Z8C6Vs/
kixlfFVGGZVaglxR9Vgs13Srht0aE4LgE2BiUwJe5szicGRr7M/OXCN/
yS2fH5qbuHyJHdP3UiEliNleuYLO+U0ALN0XXVrFJ+FF+eyoFNKGETl+tg2Ruevh7tuVgMLD6jFhZwkm7hkS
eoG4h22rMYQ0EEJc/rjYuwT/xZySOhIIwbpg/TdDtoQi7j4Cru0b5BibZkcfRxQDhzqIvAPi7U113i7qPq/
jiC2fqnRoxl2lVuPuwCyEhDnWHatBT/
oIPEpJfvg7+zvnGk3PHvlpH3G6A85oEWFa8tbCkCt9ca8exwJCmbNCEbBnWL/
tl75HOGNfTweqNxoggQNbLEG8mmxDu9t5e/
LSDyeDycJ0CE2f8kFh+E7RGw6xznyUtS9c0CasOi0kAeXZ9fm1JRrYlAR+ADYECvRYmQEOfgpio/
2+vjTmBU0rmTSZkoNY5Ijw+SYljCzgjc9JX9Rt+EpRqnYm3BFBCg0yzW2bLyKFOZSYzbuHr0NXpJY50V04An
/Glj6Cv/vjPE8wUTkUecRBwYuyezNBPY7m7AU6sd1hTMcL3sDTJ2pzEJT56wKcV9zjnoQyBmrwatPjpU----
-END CERTIFICATE-----"
                   authenticate-client true
                   cipher-list [
                       aes128-sha256
                       des-cbc3-sha
                       camellia128-sha
                   ]
            }
        }
 }

Generating a self-signed certificate

From the SR Linux CLI, you can create a self-signed certificate and key. By default, SHA-256 hash functions with RSA encryption are used for the signature algorithm. Private keys are not encrypted using DES/3 and are 4096 bits in length.

The following example generates a private key, followed by the self signed certificate:

# tools system tls generate-self-signed email info@nokia.com country us organization nokia
/system/tls:
-----BEGIN PRIVATE KEY-----
MIIJRAIBADANBgkqhkiG9w0BAQEFAASCCS4wggkqAgEAAoICAQC3Q7PnCWjevlFn
--snip--
1ecXRjvpRvIEDUWYqVOioMfCaWxJoTJUX6HgjIY0Z9ktfWiceX1Ka4e3ZxIpEC4p
SvzKsoCTqpQcIk5pCsALhznOO6ArtPc4
-----END PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
MIIE/TCCAuWgAwIBAgIJAKzAUREbPIV1MA0GCSqGSIb3DQEBCwUAMBQxEjAQBgNV
--snip-
BTTcAiQnIIkdJ0niqE+ZcOneSgxP3dKEovWQ+Bh3ES2QLsqbDvBYjz4eBoDigaAZ
KDnK207h3hiKLAaxMbAQeWGiu2ZKoKKdd4QE6OphOw6T
-----END CERTIFICATE-----

This tools command example is equivalent to the following openssl command:

# openssl req -x509 -newkey rsa:4096 -days 365

Generating a certificate signing request

You can issue a CLI command that returns a private key and certificate signing request (CSR). This CSR can be passed to a certificate authority (the same one that the client/server uses to validate certificates on either side) for the certificate authority to sign the request; the CSR cannot be used as-is.

The following command returns the private key, followed by the CSR:

# tools system tls generate-csr email info@nokia.com country us organization nokia
/system/tls:
-----BEGIN PRIVATE KEY-----
MIIJRAIBADANBgkqhkiG9w0BAQEFAASCCS4wggkqAgEAAoICAQC3Q7PnCWjevlFn
--snip--
1ecXRjvpRvIEDUWYqVOioMfCaWxJoTJUX6HgjIY0Z9ktfWiceX1Ka4e3ZxIpEC4p
SvzKsoCTqpQcIk5pCsALhznOO6ArtPc4
-----END PRIVATE KEY-----
-----BEGIN CERTIFICATE REQUEST-----
MIIC5TCCAc0CAQAwgZ8xCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlh
vy3MjE7rJtmWTg0pTfiuU4BFoAzLhHRN1hl1mXuE2m6XJ8gvBPp2sN7SvieUCy/L
RVTs+/Fmcc4vMjx3t/0hAewIsd7DNe+kVQ==
-----END CERTIFICATE REQUEST-----

This tools command example is equivalent to the following openssl command:

# openssl req -newkey rsa:4096

SPIFFE

SPIFFE (Secure Production Identity Framework for Everyone) is a framework that enables services to bootstrap and obtain identity. SPIFFE enables a central authority (CA) to issue signed certificates for identifying clients and servers, establishing mutual trust among them based on their trust in the CA.

SPIFFE is applicable only for TLS sessions and is not used when system is accessed over SSH/CLI or any other non-TLS interfaces.

SPIFFE defines an identity document known as the SPIFFE Verifiable Identity Document (SVID). This is a cryptographically-verifiable document that contains a SPIFFE ID, which represents the identity of a service. SVIDs can be encoded in two formats: X.509 certificates or JWT tokens1.

Note: SR Linux supports X.509 certificates as SVIDs only.

In an X.509 SVID, the corresponding SPIFFE ID is set as a URI type in the Subject Alternative Name (SAN) extension (subjectAltName) field. The SVID only supports one URI field in the SAN extension. You can add multiple IP or DNS fields to the SAN, but there must be only one URI in the SAN.

A SPIFFE-ID is a URI that starts with spiffe scheme, followed by a FQDN and a path that identifies the user. For example,

spiffe://nokia.com/sa/alice

where, nokia.com refers to the domain name, and alice refers to the user.

SPIFFE is used for authentication only. Authorization is performed by the role assigned to the user referred by the SPIFFE-ID.

Leveraging SPIFFE

The high-level steps for leveraging SPIFFE are as follows:

Create two sets of certificates, one for the server and one for the client. These certificates should be signed by a Certificate Authority (CA).
Configure a TLS profile on the system with authenticate-client parameter set to true and the trust-anchor parameter set to the public certificate of the CA that was used to sign the client and server certificates. For more information, see Configuring a TLS profile.
Reference the TLS profile to use on a TLS supporting server. For configuration examples, see the sections that correspond to the TLS server you are using:
- For gNMI server configurations, see Configuring a gNMI server.
- For gRIBI server configurations, see the section "Enabling the gRIBI server for a network-instance" in SR Linux gRIBI Guide.
- For P4Runtime server configurations, see the section "Configuring the P4Runtime server for a network-instance" in SR Linux P4RT Guide.
Note: SPIFFE is not supported for JSON-RPC servers.
Configure a SPIFFE-ID for a user. For instructions, see Configuring SPIFFE-ID for users.

Note:

The TLS supporting server does not check the SPIFFE-ID in the client’s X.509 certificate unless you enable mTLS (set .system.tls.server-profile[].authenticate.client to true). Additionally, the presence of a SPIFFE-ID in the client's X.509 certificate does not necessarily indicate support for mTLS.

Configuring SPIFFE-ID for users

The SPIFFE-ID list is configured under .system.aaa.authentication.user. The format of SPIFFE-ID is spiffe://<domain-name>/<user>.

Configure SPIFFE-ID for a local user

--{ * candidate shared default }--[  ]--
# info system aaa authentication user srl-test-user spiffe-ids
    system {
        aaa {
            authentication {
                user srl-test-user {
                    spiffe-ids [
                        spiffe://nokia.com/srl-test-user
                    ]
                }
            }
        }
    }

Configure SPIFFE-ID for a admin user

--{ * candidate shared default }--[  ]--
# info system aaa authentication admin-user spiffe-ids
    system {
        aaa {
            authentication {
                user admin-user {
                    spiffe-ids [
                        spiffe://nokia.com/admin-user
                    ]
                }
            }
        }
    }

Using SPIFFE for client authentication (mTLS)

In a handshake with TLS client authentication (authenticate-client enabled), the server expects the client to present its X.509 certificate.

In cases where the client's X.509 certificate contains a SPIFFE-ID, the SPIFFE-ID is checked for a match with any SPIFFE-ID configured within the spiffe-ids field in the user configuration. When a match is found, the client receives the permissions granted to that user. The user is rejected if there is no match.

If the X.509 certificate provided by the client does not contain a SPIFFE-ID, the behavior depends on whether the TLS supporting server has enabled the use-authentication or not. When enabled, the HTTP metadata is checked for the username and password. To proceed with authentication, both the username and password must be provided. When the use-authentication is not enabled, the client is rejected.