Le fichier de règles d'autorisation est une source unique d'informations fiables pour la configuration d'autorisation de la pile de communication du véhicule défini par logiciel (SDV) pour un pack de services SDV.
Le fichier de règles d'autorisation contient la liste des autorisations pour ce pack de services, qui spécifie ce que le pack peut faire.
Schéma Proto
Le fichier de règles d'autorisation utilise le format textproto pour encoder les informations pertinentes.
Le schéma Proto de la règle d'autorisation est le suivant :
message AuthzPolicy {
// Optional. List of permissions to publish Data Tunnel publications.
repeated Publisher publisher = 4;
// Optional. List of permissions to discover and subscribe to Data Tunnel
// publications.
repeated Subscriber subscriber = 5;
// Optional. List of permissions to serve an RPC server.
repeated Server server = 6;
// Optional. List of permissions to discover and call methods of an RPC
// server.
repeated Client client = 7;
// Optional. Allow blanket "read" permission.
//
// Gives permission to discover and call all methods of all RPC servers,
// as well as discover and subscribe to all publications.
//
// WARNING: This flag grants elevated permissions and should be used with a
// good reason and for privileged agents only (e.g. Telemetry).
bool allow_read_all = 8;
}
// Defines a permission to publish Data Tunnel publications.
message Publisher {
// Required. Publication's protobuf message name.
string message = 1;
// Topic(s) to which this permission allows to publish to.
//
// Setting this field or setting 'allow_all_topics == true' is required.
repeated string topic = 2;
// Flag indicates that Service Bundle is allowed to register publication
// of the 'message' type with any 'topic'
//
// Should only be set to 'true' if the 'topic' field is not set.
bool allow_all_topics = 3;
}
// Defines a permission to discover and subscribe to Data Tunnel publications.
message Subscriber {
// Required. Publication's protobuf message name.
string message = 1;
// Topic(s) to which this permission allows to subscribe to.
//
// Setting this field or setting 'allow_all_topics == true' is required.
repeated string topic = 2;
// Flag indicates that Service Bundle is allowed to discover and subscribe to
// all publications of the 'message' type.
//
// Should only be set to 'true' if the 'topic' field is not set.
bool allow_all_topics = 3;
}
// Defines a permission to serve an RPC server.
message Server {
// Required. Server's protobuf service name.
string service = 1;
// Channel(s) which this permission allows to register.
//
// Setting this field or setting 'allow_all_channels == true' is required.
repeated string channel = 2;
// Flag indicates that Service Bundle is allowed to register RPC servers
// of the 'service' type with any 'channel'
//
// Should only be set to 'true' if the 'channel' field is not set.
bool allow_all_channels = 3;
}
// Defines a permission to discover and call methods of an RPC server.
message Client {
// Required. Server's protobuf service name.
string service = 1;
// Channel(s) which this permission allows to discover and call methods on.
//
// Setting this field or setting 'allow_all_channels == true' is required.
repeated string channel = 2;
// Flag indicates that Service Bundle is allowed to discover and call all RPC
// servers of the 'service' type.
//
// Should only be set to 'true' if the 'channel' field is not set.
bool allow_all_channels = 3;
}
Exemple
# Allows this SB to register publication of TireStatus type with "left_tire" topic only.
publisher {
message: "com.sdv.TireStatus"
topic: "left_tire"
}
# Allows this SB to subscribe to publication of TireStatus type with "left_tire" topic only.
subscriber {
message: "com.sdv.TireStatus"
topic: "left_tire"
}
# Allows this SB to implement and serve UserPreferencesManager service on any channel.
server {
service: "com.sdv.UserPreferencesManager"
allow_all_channels: true
}
# Allows this SB to discover and call UserPreferencesManager service on any channel.
client {
service: "com.sdv.UserPreferencesManager"
allow_all_channels: true
}
Exemple de lecture privilégiée de tous les éléments
# Blanket read permission for privileged agents (e.g. Telemetry).
allow_read_all: true
Décision d'autorisation
Le système peut prendre les décisions d'autorisation suivantes :
- Contenu autorisé
- Le
AuthzPolicydu sujet contient la règle d'autorisation requise. - Refusé explicitement
- Le
AuthzPolicydu sujet ou leAuthzPolicyde la VM ne contient pas la règle d'autorisation requise. Un message d'erreur clair est renvoyé, indiquant l'autorisation manquante. - Refusé implicitement
- Erreur système ou données non valides, telles qu'un fichier de règles manquant, un échec d'analyse d'un nom ou une définition d'unité manquante.
Exemple de logique de décision
Les étapes suivantes se produisent lorsqu'un pack de services tente d'appeler com.sdv.UserPreferencesManager sur le canal default :
- La pile de communication vérifie l'autorisation
clientduAuthzPolicydu pack de services. Si l'autorisation est manquante, la requête est Refusée explicitement, ce qui indique que le sujet ne dispose pas de l'autorisation. - Pour la communication entre les VM sur le réseau maillé, l'autorisation de la VM hôte est vérifiée lors de l'échange d'informations maillées de la découverte de services (SD), et pas seulement lors de la tentative d'accès. La pile de communication vérifie le
VmAuthzPolicyde la VM hôte pour déterminer si la VM est autorisée à interagir avec le service. - Si la règle du sujet et la règle au niveau de la VM autorisent l'interaction, la requête est Autorisée. Sinon, elle est Refusée explicitement, ce qui indique que la VM ne dispose pas de l'autorisation.
Pour en savoir plus sur les règles appliquées entre les VM, consultez la section Autorisations au niveau de la VM.