gNSI

The Authz policy consists of the following:

• name: name for the policy defined by the client
• allow_rules list (mandatory): list of allow rules for the policy
• deny_rules list (optional): list of deny rules for the policy

Allow and deny rules

Each allow or deny list is comprised of instances of rules. Each rule consists of the following:

• name: name for the rule defined by the client; similar to the policy name
• source: a holding container with a single source type of principals:
  • principals: a list of principals that must match against user objects, be it one of the users defined in system aaa authentication user, a remotely resolved user from a system aaa server-group, or the admin
• request contains:
  • paths: a list of gRPC RPC paths (in format pkg.Service/Rpc) that this policy applies to; for example: /gnoi.os.OS/Install (if no paths are provided, all paths are matched)
  • headers: a list of key/value pairs matching HTTP headers
    Note: SR Linux does not support matching on headers.

Matching source and request

Both the source and request fields must match in order for a rule to match. If both source and request are empty, the rule always matches. Empty source and request can serve as a wildcard in a deny_rules list to deny all RPCs or in an allow_list to accept all RPCs except those matching in the deny_rules list.

If only the source is empty, the paths provided in the request field apply to all users system wide. Similarly if only the request is empty then the action (deny or allow) is applied to all users provided in the source. If no paths are specified in the request, all paths are matched.

Authz policy persistence

As it is a requirement to persist a policy after it has been finalized, on finalization the current policy is written to /etc/opt/srlinux/gnsi/authz-policy.json. This policy is read by the SR Linux gNSI server on startup and exposed as the active policy.

It is an Authz requirement that if a policy is configured, no gRPC servers (this includes P4RT, gRIBI, gNOI, gNMI, and gNSI externally) can start until the policy is successfully activated. The Authz scope is to protect access to system RPCs from malicious entities, so a policy must be active before ports are opened.

Default Authz policy

As part of the default SR Linux configuration, the Authz service is running, and a default Authz policy controls access to every active gRPC service. The result of the default policy is that any authenticated user is permitted full access to any currently active service and gRPC. This does not overrule any subsequent role-based access control that exists on the system.

 {
  "name": "Default policy", 
  "deny_rules": [],  
  "allow_rules": [    
   {                  
    "name": "admin-access",  
    "source": {   
     "principals": [   
      "*"  
     ]   
    },    
    "request": {   
     "paths": [    
      "/*",     
      ""      
     ],    
     "headers": []    
    }    
   }    
  ]   
 }

Authz interactions with role-based access control and service authorization

The Authz service operates in addition to existing role-based access control and service authorization. As a result, to provide a user access to a gRPC, you must configure their access under role-based access control and service authorization (for example, system aaa authorization role services gnmi) in addition to enabling access using the Authz service. The system aaa authorization role services command also supports defining service authorization for gnsi.

Order of authorization

The order of authorization is as follows:

1. Check service authorization first; only if the user is authorized for the service are they admitted.
2. If the interface is a gRPC interface, check the Authz policy to see if the user is authorized for the specified RPC.
3. If the user is configuring or reading any paths, perform role-based access control.

To allow the gNMI (and gNSI) server to start as part of the default configuration, the factory default configuration includes a TLS profile named __default__. This default policy does not authenticate the identity of connecting clients. You can view the policy using the info from state system tls server-profile __default__ command.

# info from state system tls server-profile __default__
   system {
        tls {
            server-profile __default__ {
                key $aes1$4lL6SVq5G8=$FqANWbk8TQmrGYB1cTuaplFUZTZlAP992Debrq4X2ZjfOde4wA
                ...
                certificate "-----BEGIN CERTIFICATE-----
MIIFLzCCAxegAwIBAgIUBQFYPrWyBalNUfTNCBUAMiWrk2kwDQYJKoZIhvcNAQEL
BQAwHTEOMAwGA1UEAwwFc3JsZDUxCzAJBgNVBAYTAlVTMCAXDTI0MDIyMDIzNTY0
...
-----END CERTIFICATE-----
"
                authenticate-client false
                dynamic true
                cipher-list [
                    ecdhe-ecdsa-aes256-gcm-sha384
                    ecdhe-ecdsa-aes128-gcm-sha256
                    ecdhe-rsa-aes256-gcm-sha384
                    ecdhe-rsa-aes128-gcm-sha256
                ]
            }
        }
    }

SR Linux also supports a default TLS configuration option for the gRPC server (system grpc-server name default-tls-profile [true | false]) that controls whether the system uses the default TLS profile if none are configured using the tls-profile option. If default-tls-profile is set to false (the default value), and no tls-profile is defined, then TLS is disabled entirely from the system.

SR Linux supports the following Authz service RPCs:

• Rotate RPC
• Probe RPC
• Get RPC

Rotate RPC structure

rpc Rotate(stream RotateAuthzRequest) returns (stream RotateAuthzResponse);

Probe RPC structure

rpc Probe(ProbeRequest) returns (ProbeResponse);

Get RPC structure

 rpc Get(GetRequest) returns (GetResponse);

Rotate RPC structure

rpc Rotate(stream RotateCertificateRequest) returns (stream RotateCertificateResponse);

CanGenerateCSR RPC structure

rpc CanGenerateCSR(CanGenerateCSRRequest) returns (CanGenerateCSRResponse);

AddProfile RPC structure

rpc AddProfile(AddProfileRequest) returns (AddProfileResponse);

DeleteProfile RPC structure

rpc DeleteProfile(DeleteProfileRequest) returns (DeleteProfileResponse);

GetProfileList RPC structure

rpc GetProfileList(GetProfileListRequest) returns (GetProfileListResponse);

Certz state paths are available under system tls server-profile. These paths indicate the certificate, trust bundle, and CRL in use by each specific instance of a gRPC server.