Zum Inhalt springen
actor-ts
Deutsch

TLS everywhere

Produktions-sicher heißt TLS auf jeder Netzwerkoberfläche. Jede Komponente des Frameworks hat ihre eigene TLS-Konfiguration; diese Seite ist der Katalog, wo TLS zu aktivieren ist und welches Cert-Material jede Komponente braucht.

Cluster-Transport

Abschnitt betitelt „Cluster-Transport“
import { TcpTransport, Cluster } from 'actor-ts';


const transport = new TcpTransport(self, log, {
  cert: fs.readFileSync('./tls/cluster.crt'),
  key:  fs.readFileSync('./tls/cluster.key'),
  ca:   fs.readFileSync('./tls/ca.crt'),
  rejectUnauthorized: true,
});


await Cluster.join(system, { host, port, seeds, transport });

Mutually authenticated TLS zwischen Cluster-Nodes. Siehe Cluster-Sicherheit für die vollständige Diskussion.

Nicht überspringen — auch in internen Netzwerken gilt Defense in Depth.

HTTP-Server

Abschnitt betitelt „HTTP-Server“
import { HttpExtensionId } from 'actor-ts';


const http = system.extension(HttpExtensionId);


await http.newServerAt('0.0.0.0', 8443)
  .useBackend(new FastifyBackend({
    tls: {
      cert: fs.readFileSync('./tls/http.crt'),
      key:  fs.readFileSync('./tls/http.key'),
    },
  }))
  .bind(routes);

Für HTTPS auf der Anwendungsebene. Oft am Load Balancer terminiert stattdessen — in K8s übernimmt Service/Ingress TLS, die App spricht intern Plain-HTTP. Wählen je nach Form deiner Infrastruktur.

Management-Endpunkt

Abschnitt betitelt „Management-Endpunkt“
await HttpManagement.start(system, {
  port: 8558,
  tls:  {
    cert: fs.readFileSync('./tls/mgmt.crt'),
    key:  fs.readFileSync('./tls/mgmt.key'),
  },
});

Der Management-Server ist standardmäßig nur intern — aber TLS hilft trotzdem:

  • Schützt vor lateraler Bewegung in einem kompromittierten Netzwerk.
  • Wird von manchen Compliance-Regimen unabhängig von der Netzwerk-Topologie verlangt.

Broker-Actors

Abschnitt betitelt „Broker-Actors“

Jeder Broker-Actor hat seine eigenen TLS-Knöpfe:

Kafka

Abschnitt betitelt „Kafka“
new KafkaActor({
  brokers: ['kafka-1:9093'],
  ssl:     true,
  sasl: {
    mechanism: 'scram-sha-512',
    username: process.env.KAFKA_USER!,
    password: process.env.KAFKA_PASS!,
  },
});

MQTT

Abschnitt betitelt „MQTT“
new MqttActor({
  url:      'mqtts://mqtt.example.com:8883',
  username: process.env.MQTT_USER,
  password: process.env.MQTT_PASS,
});

mqtts://-URL-Schema. Cert-Verifizierung folgt den Defaults des zugrundeliegenden mqtt-Pakets.

AMQP

Abschnitt betitelt „AMQP“
new AmqpActor({
  url: 'amqps://rabbitmq.example.com:5671',
  // amqplib nutzt URL-Parameter für die TLS-Konfiguration
});

amqps://-URL-Schema.

NATS

Abschnitt betitelt „NATS“
new NatsActor({
  servers: ['nats://nats.example.com:4222'],
  tls: {
    ca:   fs.readFileSync('./tls/nats-ca.crt'),
    cert: fs.readFileSync('./tls/nats-client.crt'),
    key:  fs.readFileSync('./tls/nats-client.key'),
  },
});

mTLS via das tls-Objekt — üblich für Produktions-NATS.

Redis Streams

Abschnitt betitelt „Redis Streams“
new RedisStreamsActor({
  url: 'rediss://redis.example.com:6380',
  tls: true,
});

rediss://-URL-Schema (beachte das doppelte s).

gRPC

Abschnitt betitelt „gRPC“
new GrpcClientActor({
  target: 'orders.example.com:50051',
  tls: {
    ca: fs.readFileSync('./tls/ca.crt'),
  },
});

Für Mutual TLS cert + key ergänzen.

WebSocket

Abschnitt betitelt „WebSocket“
new WebSocketActor({
  url: 'wss://realtime.example.com/feed',
});

wss://-URL-Schema. Cert-Verifizierung folgt den TLS-Defaults der Runtime.

Persistence-Backends

Abschnitt betitelt „Persistence-Backends“

SQLite

Abschnitt betitelt „SQLite“
Nicht zutreffend — lokaler Datei-Zugriff. TLS nicht anwendbar.

Cassandra

Abschnitt betitelt „Cassandra“
new CassandraJournal({
  contactPoints: ['cass-1.example.com:9042'],
  ssl: {
    cert: fs.readFileSync('./tls/cass-client.crt'),
    key:  fs.readFileSync('./tls/cass-client.key'),
    ca:   fs.readFileSync('./tls/cass-ca.crt'),
  },
});

Cassandra-Cluster laufen in Produktion typischerweise mit mTLS.

Object Storage

Abschnitt betitelt „Object Storage“
new ObjectStorageDurableStateStore({
  backend: new S3Backend({
    region: 'eu-west-1',
    // S3 nutzt per Default HTTPS
  }),
});

Cloud-Object-Storage (S3, GCS, Azure Blob) nutzt immer TLS. Keine Konfiguration nötig außer dem Endpoint.

Cert-Provisionierung

Abschnitt betitelt „Cert-Provisionierung“

Drei Muster in K8s-Produktion:

cert-manager

Abschnitt betitelt „cert-manager“
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: actor-ts-cluster
spec:
  secretName: actor-ts-cluster-tls
  issuerRef:
    name: actor-ts-ca
    kind: ClusterIssuer
  commonName: actor-ts
  dnsNames: [actor-ts-cluster.svc]
  duration: 8760h
  renewBefore: 720h

cert-manager erneuert Certs automatisch vor Ablauf. Die meisten Produktions-K8s-Setups nutzen ihn.

Vault Agent

Abschnitt betitelt „Vault Agent“

Vault Agent läuft als Sidecar; zieht Certs in das Pod-Filesystem; erneuert automatisch. Nützlich, wenn du schon HashiCorp Vault hast.

Manuell + geplante Rotation

Abschnitt betitelt „Manuell + geplante Rotation“

Für Nicht-K8s-Umgebungen geplante Cron-Jobs, die frische Certs aus einer internen CA ziehen + die betroffenen Services neu starten. Funktioniert, erfordert aber sorgfältige operative Disziplin.

Was ist mit der CA-Kette?

Abschnitt betitelt „Was ist mit der CA-Kette?“
ca: fs.readFileSync('./tls/ca.crt'),

Die meisten internen Setups: eine CA, signiert alle Client- + Server-Certs. Die Cert-Verifizierung braucht das CA-Cert auf beiden Enden.

Cloud-managed Certificates (Let’s Encrypt, AWS ACM): nutze öffentliche CA-Bundles — in den meisten Runtimes bereits vorhanden. Kein expliziter ca nötig.

Wohin als nächstes

Abschnitt betitelt „Wohin als nächstes“