gNSI

To validate a gRPC authorization, gNSI performs the following actions:

1. Check the user and RPC combination against any deny_rules. If a match is found, the request is denied. If no match is found or there are no deny_rules, execute the next step.
2. Check for a match against any allow_rules. If a match is found, the request is permitted. If no match is found, deny the request.

The Authz Rotate RPC allows a client to replace an existing gRPC authorization policy on the target node.

If any steps in the Rotate RPC process fail, the target node rolls back any changes made by the RPC.

Only one Rotate RPC can be in progress at a time. If a client attempts to call the RPC while another call is already in progress, the second call is rejected with a gRPC error of UNAVAILABLE.

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

The Authz Probe RPC tests the currently active policy. It allows the Authz policy engine on the target node to provide a response to a specified gRPC call without actually performing the gRPC operation. The current policy can be one that has not been finalized, but this is not a requirement.

The Probe RPC expects a single ProbeRequest message, and returns a ProbeResponse. The ProbeRequest does not result in an actual gRPC call being made; it simply validates whether the call can succeed with the provided user and RPC information.

rpc Probe(ProbeRequest) returns (ProbeResponse);

The Authz Get RPC returns the currently active gRPC authorization policy, as well as the policy version and created-on timestamp.

 rpc Get(GetRequest) returns (GetResponse);

To allow the gNSI Authz behavior to be invoked in the CLI or by a gNMI or JSON-RPC client, SR Linux supports the following tools commands:

• tools system aaa authorization authz-policy clear
• tools system aaa authorization authz-policy probe
• tools system aaa authorization authz-policy remove
• tools system aaa authorization authz-policy rotate

The Certz Rotate RPC allows a client to replace an existing certificate, trust bundle, CRL, or some combination of these artifacts on the target node. Either the target node or the client can generate the CSR for the new device certificate. If the client generates the CSR, it must also provide the corresponding private key with the signed certificate.

Only one Rotate RPC can be active at once. If SR Linux detects an additional Rotate RPC, it returns an error.

The Rotate RPC accepts a stream of RotateCertificateRequest messages and returns a stream of RotateCertificateResponse messages in response. A client uses the RPC to upload a certificate by specifying the certificate in a rotate_request before testing the new certificate (out of band of the RPC) and finalizing the result with a finalize_rotation. Until the target node receives the finalize_rotation, the change is transient and not persistent on disk. If the RPC is canceled for any reason before a finalize_rotation is received, then the system reverts all services using TLS to the previous values.

If the stream is broken or any of the steps fail, the target node rolls back to the original state, reverting any changes to any artifact.

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

The Certz CanGenerateCSR RPC tests whether the target node is able to generate a CSR given provided parameters. The CanGenerateCSR RPC consists of a single CanGenerateCSRRequest message and returns a CanGenerateCSRResponse. The client includes the parameters that it wants the target node to test for the CSR generation, including:

• key_type: the algorithm used for generation of the key pair (for example, KEY_TYPE_RSA)
• signature_algorithm_type: the signature algorithm used to generate the key pair (for example: SIGNATURE_ALGORITHM_SHA512_WITH_RSA)
• certificate_type: the type of certificate to create (for example, CERTIFICATE_TYPE_X509)
• key_size_bits: a uint32, indicating the size of the key in bits (for example, 2048)

rpc CanGenerateCSR(CanGenerateCSRRequest) returns (CanGenerateCSRResponse);

The Certz AddProfile RPC allows a client to add a new TLS profile to the target node. All elements of the added profile (certificate, CA trust bundle, and CRLs) are initially empty. The client must subsequently populate the artifacts using a Rotate RPC.

If a client attempts to add a pre-existing profile, the attempt is rejected with an error.

rpc AddProfile(AddProfileRequest) returns (AddProfileResponse);

The Certz DeleteProfile allows a client to remove an existing TLS profile.

The __default__ profile used by the gRPC server cannot be deleted. If a client attempts to delete the __default__ profile, the attempt is rejected with an error.

rpc DeleteProfile(DeleteProfileRequest) returns (DeleteProfileResponse);

The Certz GetProfileList RPC allows a client to retrieve a list of the TLS profile IDs that are present on a target node.

rpc GetProfileList(GetProfileListRequest) returns (GetProfileListResponse);

To allow the gNSI Certz RPC behavior to be invoked in the CLI or by a gNMI or JSON-RPC client, SR Linux supports the following tools commands:

The RecordSubscribe RPC is used in the Acctz service to accept a stream of RecordRequest messages and then return a stream of RecordResponse messages.

The RecordSubscribe RPC also maintains a history of accounting records that can be retrieved periodically by connected collector devices.

A SessionInfo message is returned with every RecordResponse message. The SessionInfo message contains information about the context in which the service record was generated.

rpc RecordSubscribe(stream RecordRequest) returns (stream RecordResponse);

The GetIAKCert RPC is used in the EnrollZ service to retrieve the Initial Device Identity (IDevID) and Initial Attestation Key (IAK) certificates from each router control card.

The GetIAKCert RPC uses the structure GetIakCertRequest for the request data, which includes the selection of a control card.

rpc GetIakCert(GetIakCertRequest) returns (GetIakCertResponse);

The RotateOIakCert RPC stores the owner Initial Device Identity (oIDevID) and owner Initial Attestation Key (oIAK) in each router control card. The oIDevID and oIAK are certificates signed by the owner CA for the associated IDevID and IAK public keys in the same control card.

When the ssl_profile_id is specified in RotateOIakCertRequest, the TLS server-profile configuration is changed to use-tpm-devid oidevid. For configuration details, see Configure TLS profile to use IDevID key with oIDevID certificate.

The RotateOIakCert RPC uses the structure RotateOIakCertResponse for the response data.

rpc RotateOIakCert(RotateOIakCertRequest) returns (RotateOIakCertResponse);

The Pathz gNMI authorization policy provides a framework for controlling which gNMI paths a user can access.

If a matching rule does not exist in the policy, an implicit deny is assumed.

/a/b[key=FOO]/c/d
/a/b[key=*]/c/d

version: "UUID-1234-123123-123123"
created_on: 1234567890
# Define 2 groups.
group {
  name: "family-group"
  members { name: "stevie" }
  members { name: "brian" }
}
group {
  name: "test-group"
  members { name: "crusty" }
  members { name: "the-clown" }
}
# Action stevie to access /this/is/a/message_path in a READ manner.
policy {
  id: "one"
  path {
    origin: "foo"
    elem { name: "this" }
    elem { name: "is" }
    elem { name: "a" }
    elem { name: "message_path" }
  }
  action: PERMIT
  mode: READ
  user { name: "stevie" }
}

There are two ways to implement policy rules with Pathz:

• Create one internal group per user with each group name matching the user name, and apply the policy rule to the internal group.
• Assign the native RBAC model directly to the user, where the user is directly assigned a mgmt_server role independent of the aaa_mgr groups.

The Pathz Rotate RPC replaces an existing Pathz authorization policy (or loads an initial policy) on the target node. If the stream is broken or any steps in the process fail, the target node rolls back any changes made by the RPC.

Only one Rotate RPC can be in progress at a time. If a client attempts to call the RPC while another call is already in progress, the second call is rejected with a gRPC error of UNAVAILABLE.

During a Rotate RPC, the policy provided in the UploadRequest does not become an active policy until a FinalizeRequest message is received. If the target node responds to the FinalizeRequest message with an error, the Pathz policy updates are rolled back.

rpc Rotate(stream RotateRequest) returns (stream RotateResponse);

During a Rotate operation, the Probe RPC allows a client to test the pending policy before finalizing the policy rotation. The RPC allows the Pathz policy engine on the target node to provide a response to a specified gNMI operation performed on a single gNMI path by a user. The target node returns the response without actually performing the gNMI operation. The RPC can be used to test the active policy at any time.

rpc Probe(ProbeRequest) returns (ProbeResponse);

The Get RPC returns the gNMI authorization policy requested in the RPC, as well as the policy version and created-on timestamp.

 rpc Get(GetRequest) returns (GetResponse);