Autorisierungsrichtlinie

Die Autorisierungsrichtliniendatei ist die Single Source of Truth für die Autorisierungskonfiguration des Software-Defined Vehicle (SDV)-Kommunikationsstacks für ein SDV-Dienstpaket.

Die Autorisierungsrichtliniendatei enthält die Liste der Berechtigungen für dieses Dienstpaket, in der festgelegt ist, was das Paket tun kann.

Proto-Schema

Die Autorisierungsrichtliniendatei verwendet das Textproto-Format zur Codierung relevanter Informationen.

Das Proto-Schema der Autorisierungsrichtlinie sieht so aus:

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;
}

Beispiel

# 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
}

Beispiel für privilegierten Lesezugriff

# Blanket read permission for privileged agents (e.g. Telemetry).
allow_read_all: true

Autorisierungsentscheidung

Das System kann die folgenden Autorisierungsentscheidungen treffen:

Zulässig
Die AuthzPolicy des Subjekts enthält die erforderliche Berechtigungsregel.
Ausdrücklich abgelehnt
Die AuthzPolicy des Subjekts oder die AuthzPolicy der VM enthält nicht die erforderliche Berechtigungsregel. Es wird eine klare Fehlermeldung zurückgegeben, die die fehlende Berechtigung angibt.
Stillschweigend abgelehnt
Systemfehler oder ungültige Daten, z. B. eine fehlende Richtliniendatei, ein Fehler beim Parsen eines Namens oder eine fehlende Einheitsdefinition.

Beispiel für Entscheidungslogik

Die folgenden Schritte werden ausgeführt, wenn ein Dienstpaket versucht, com.sdv.UserPreferencesManager auf dem Kanal default aufzurufen:

  1. Der Kommunikationsstack prüft die AuthzPolicy des Dienstpakets auf die Berechtigung client. Wenn die Berechtigung fehlt, wird die Anfrage Ausdrücklich abgelehnt, was darauf hinweist, dass das Subjekt keine Berechtigung hat.
  2. Bei der VM-übergreifenden Kommunikation über das Mesh-Netzwerk wird die Berechtigung der Host-VM während des Mesh-Informationsaustauschs der Dienstermittlung (Service Discovery, SD) geprüft und nicht nur beim Zugriffsversuch. Der Kommunikationsstack prüft die VmAuthzPolicy der Host-VM, um festzustellen, ob die VM mit dem Dienst interagieren darf.
  3. Wenn sowohl die Subjektrichtlinie als auch die Richtlinie auf VM-Ebene die Interaktion zulassen, wird die Anfrage als Zulässig eingestuft. Andernfalls wird sie Ausdrücklich abgelehnt, was darauf hinweist, dass die VM keine Berechtigung hat.

Weitere Informationen zu Richtlinien, die zwischen VMs erzwungen werden, finden Sie unter Berechtigungen auf VM-Ebene.