ankn/Orchestrator
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
master
Orchestrator/bahn/project-audit/data/confluence-export/pages/161972468_Archiv CNP JF.md
T
ankn a5f8fb49ab Migrate all repos into monorepo context folders 
Bahn: aisupport, Analyse-O2C-C2S, awesome-bahn-mcp-servers, beam-mcp,
      Confluence_Bot, db-planet-mcp-server, O2C-Harness, project-audit,
      Projekt-KIQ-HP, teamlandkarte-mcp
Dhive: Jury-Voting
Privat: CV, NoteGraph (NOTE: NoteGraph needs complete redo after consolidation)
Shared: AI-Orchestrator, OrgMyLife, power_skills_and_more
Shared/references: symphony (read-only)

Bahn repos remain available as independent remotes - this monorepo
pulls them in via subtree, the originals are untouched.
2026-06-30 20:39:52 +02:00

40 KiB
Raw Permalink Blame History

Archiv CNP JF

Confluence Page ID: 161972468 Version: 2 Pfad: /pathOS/Kommunikationskanäle, Termine, Besprechungsnotizen pathOS/Besprechungsnotizen/Abstimmungen mit Cloud Native Platform (CNP)/Archiv CNP JF Labels:

Termin 26.10.2021

Teilnehmen: Annette, Bing, Bishara, Diego, Konstantin, Sean, Martin

  • Aktuelles:
  • Portal in EVU-Test: Pen-Test noch ohne Termin. Der früheste mögliche Termin ist derzeit Anfang Januar. Ein Anbieter steht allerdings noch aus. Je nach Ergebnis müssen wir eine Verschiebung oder eine bedingte Freischaltung vor dem Pentest prüfen.
  • Kurzer Review der Punkte vom 12.10.
  • Konstantin: Tracking von Bugs und Zulieferungen könnte künftig über Jira erfolgen, sobald beide (Bestellsystem und CNP) auf das neue NVI-Jira migriert sind. → im Prinzip haben wir jetzt gegenseitig JIRA-Zugriff zwischen CNP und Bestellsystem
  • Umsetzung Container-Vorgaben
  • welche Frist gilt für das Bestellsystem: 1.1.2022
  • Wie ist die Arbeitsteilung zwischen CNP und ARTs?
  • aktuell größte Lücke: privilegierte Container für Kaniko notwendig
  • Gibt es bei CNP schon einen Plan damit umzugehen?
  • Vorschlag/Planung Bestellsystem: ein eigener Namespace für Kaniko, und nur in diesem Namespace privilegierte Container zulassen. – damit können wir dann alle nicht-Build-Umgebungen absichern.
  • Martin: Ich habe neue Namespaces im Cluster bestellsystem-dev erstellt
  • Als Kürzel habe ich bsz  benutzt (angelehnt an den Projektnamen in Beam),
  • Kann bei Gelegenheit jemand bestätigen dass das Erstellen mit kubectl hnc create  so richtig war?

Ziel ist später nur noch in bsz-kaniko "privilegierte" Container zu benötigen (mangels besserer Container-Build-Lösung)

neue Namespace-Liste zur Info:

  • mit den neuen Namspaces haben wir auch begonnen zusätzliche Anwendungs-Installationen in bestellsystem-dev zu starten. Aktuell unsere 'vertriebsdemo', danach folgt 'IEU'.
  • Frage dazu: hilft es wenn wir in bestellsystem-ops die SubnamespaceAnchor Objekte einpflegen? → Ja, sollte per MR eingetragen werden.
  • Martin: Ingress Controller in bestellsystem-evu-test Der ALB-Ingress-Controller funktioniert in bestellsystem-dev gut und löst unsere offenen Probleme (HTTP-Header, Cluster-Erreichbarkeit, Portnummern im Hostnamen). Jetzt müssen wir auch bestellsystem-evu-test aktualisieren. → Sean und Martin aktualisieren evu-test am Donnerstag
  • Martin: wenn ich jetzt mehr Anwendungs-Installationen starte, dann brauche ich ein paar Monitoring-Daten von der RDS-Instanz um zu bemerken wenn wir die überlasten. (In Grafana finde ich nur eine Kombau-RDS, nicht unsere bestellsystem-dev).
  • Martin: aktuell haben wir Probleme mit DNS-Einträgen per CNP-API. → Bei Sean bereits angefragt und in Arbeit.

Termin 12.10.2021

Hinweis: Konstantin und Martin sind im Urlaub

Teilnehmen: Natalia, Annette, Bing, Bishara, Frank, Diego

  • Aktuelles:

  • Aktuelle Ingress-Probleme sind gelöst. 

  • Die Umstellung des Endpoints notwendig (Sean geht auf Diego zu)

  • Probleme mit der Testumgebung: IP-Adressen-Problem ist gelöst

  • Änderung des DNS-/Route53-Setups in Arbeit, das 63-Zeichen-Limit ist gelöst

  • Martin: Nachfrage zu Secrets:→ kein Update

  • Martin: Nachfrage zu Git-Secrets→ kein Update

  • Bishara/Martin: MasterData Proxy-Eintrag-->E-Mail via Natalia an Ops-Team

  • Status Service-Mesh (Blocker für die Verschlüsselung und Zugriffskontrolle der internen Kommunikation)→kein Update.

  • Ist jetzt als Service angeboten, wird mit IDBF vertestet

  • Ziel: zum Jahresende für das Bestellsystem zum Testen bereitstellen

  • Überblick über den Rest des Themenspeichers.

  • Monitoring: in Entwicklung→ kein Update

  • Pen-Test-Termin→ Vertrag ist da, Termine sollen vereinbart werden, Kick-Off-Termin soll organisert werden (Annete)

  • SIEM-Anbindung:

  • OS-Ebene: keine ToDo's 

  • App-Ebene: ab 2022 notwendig, Abstimmung mit SCIRT

  • Migration von Build- und Dev-Umgebungen von DBCS auf CNP

  • Dynamische DNS-Einträge und Ingress-Controller.

  • Verhalten der Cluster unter Last: Fargate vs. Cluster-Autoscaling (erstmal time-based)→ Anforderungen an Umgebungen sollen spezifiziert werden (BE→Bing, FE→Diego, Annete))

  • (weitgehender) Verzicht auf priviligierte Container erfordert eigenes Anlegen von Namespaces (Martin hat Rechte zum Anlegen der Subnamespaces).

  • Konfiguration von OPA (Spezifizieren, was damit gemeint ist). → das heißt zum Beispiel Verhindern von privilegierten Containern außerhalb des Kaniko-Namespaces.

Termin 28.09.2021

Teilnehmen: Natalia, Annette, Bing, Bishara, Edmond, Konstantin, Martin

  • Aktuelles:
  • Aktuelle Ingress-Probleme: mit Hannes (als Seans Vertretung) halb in Arbeit
  • künftige Termine/Zusammenarbeit. CNP & Projekt Dailies geplant.
  • Änderung des DNS-/Route53-Setups in Arbeit, das 63-Zeichen-Limit könnte wieder obsolet sein.
  • Übersicht aktuelle Tickets, die im Bestellsystem als externe Abhängigkeit Dinge blockieren
  • Martin: Nachfrage zu Secrets:
  • Können wir bitte irgendwo dokumentieren wie Secrets gespeichert werden müssen, um den DB-Vorgaben zu entsprechen?
  • Bisher schreiben wir unsere Secrets nur in die K8s-API, unter der Annahme dass das reicht, also dass die Daten dann nicht im K8s-etcd, sondern im AWS-SecretsManager gespeichert werden.
  • Unter  wird zusätzlich ein Secrets Claim per CNP-API beschrieben. Brauchen wir sowas auch, oder ist das schon automatisiert?
  • muss nochmal genauer besprochen werden → Folgeticket oder -Termin
  • Martin: Nachfrage zu Git-Secrets
  • Bei der Beschäftigung mit der pipeship-Implementierung für Secrets in Git-Repositories (mit PGP als Backend) sind uns Probleme aufgefallen.
  • Als Alternative wird ein AWS KMS-Schlüssel vorgeschlagen, das erscheint mir schwierig ohne AWS-Credentials für alle Entwickler.
  • Gibt es von CNP eine empfohlene Lösung, wie wir verschlüsselte Daten in Git an eine Laufzeitumgebung koppeln können?
  • muss nochmal genauer besprochen werden → Folgeticket oder -Termin
  • Bishara/Martin: Wir brauchen nochmal ein MasterData-Update (Proxy-Freigabe), wer kann uns das eintragen?
  • wir wollen von Anwendung "bestellsystem-commoninterface-test.dbnetze.com" aus zugreifen auf Hostnamen "commoninterface-dev.cos-test.comp.db.de"
  • → E-Mail via Natalia an Ops-Team
  • Status Service-Mesh (Blocker für die Verschlüsselung und Zugriffskontrolle der internen Kommunikation).
  • Ist jetzt als Service angeboten, wird mit IDBF vertestet
  • Ziel: zum Jahresende für das Bestellsystem zum Testen bereitstellen
  • Überblick über den Rest des Themenspeichers.
  • Monitoring: in Entwicklung, braucht nochmal ein Update
  • DNS-Namen für das Portal in EVU-Test sind bestätigt
  • Pen-Test-Termin weiter offen (?)

Termin 14.09.2021

Teilnehmer: Natalia, Sean, Martin, Bishara, Diego, Konstantin

  • Todos aus alten Terminen durchgehen
  • Nächste Schritte bzgl. X-Forward-Proto

128 complete : versucht den Header im LB zu setzen (Infos zum Nachstellen des Fehlers siehe das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eOO-2), siehe auch das CNP-Ticket

  • Vorgehen zum Tracken von Bugs
  • Bestellsystem tracket externe Abhängigkeit im neuen Jira
  • CNP plant ebenfalls auf das gleiche Jira umzusteigen: künftig kann Jira-intern verlinkt werden.
  • Natalia: die Einhaltung der Container-Richtlinien wurden für die DB-netz bis zum 1.1.2022 ausgesetzt. CNP arbeitet aktuell die Plattform-Vorgaben durch.
  • Martin erstellt gerade eine Todo-Liste, das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CZERO-53
  • Größte Baustelle ist Patch- und Schwachstellenmanagement (eingeplant für Q4).
  • Logging-Forwarding Richtung SIEM muss noch geklärt und eingeplant werden (komplex, aktuell bei IDBF in Besprechung).

129 complete soll für 2022 eingeplant werden. => das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-158

  • Konstantin: zur Info: wir suchen derzeit Termine für Bedrohungsanalyse+Pentest Portal für Q4
  • Dynamische DNS-Einträge: Namensstruktur muss sich ändern.

130 complete : gibt Sean Bescheid (voraussichtlich ab 17.9). => neue Namen festgelegt, durch PI-Planning leider erst spät umgesetzt

  • Zentraler Identity Provider
  • Diskussionen mit Jan-Sören Papp laufen aktuell.

Termin 31.08.2021

Teilnehmer: Bernd, Sean, Martin, Bishara, Diego

  • Sean: Probleme mit HTTP-Header X-Forward-Proto sollten spätestens bis 10.8 behoben sein. → Blocked by https://github.com/kubernetes/cloud-provider-aws/issues/234#issuecomment-885789048
  • Martin: Zugang zur CNP-API bekommen, technischer User fehlt noch.  Zugang zur CNP-API wird prinzipiell für alle Entwickler benötigt (erstmal reichen Martin, Bing, Diego, Bishara). Die API-Doku ist bisher nur als FAQ verfügbar.

123 complete  : TechUser und Freischaltungen bis 1.9

  • Martin: Monitoring ist wieder in Bestellsystem-Dev ausgefallen.
  • Sean: CNP hat einen neuen Monitoring-Experten (Hannes Blut). Die Kommunikation läuft aber erstmal weiter über Sean bzw. den CNP/Bestellsystem Teams-Kanal.
  • Umstieg auf Aurora. Hier steht noch Aurora v1 (ginge sofort) oder v2 zur Auswahl (ist noch nicht von AWS freigegeben).
124
complete
schickt eine kurze Info an Martin zu Aurora v1 (v1 reicht erstmal).

Termin 24.08.2021

Teilnehmer: Sean, Harald, Martin, Bing, Konstantin

  • Sean: Beim Monitoring sind größere Setup-Änderungen inkl. Zugriffsrechte bis 13.September geplant.
  • Dann sollten auch Anpassungen der Dashboard durch Projekte möglich sein.
  • Sean: Ingress Controller sollten bis ca. 27.8 zum Testen bereit stehen.
  • EVU-Test bzw. Portal im Internet: Nach der SOAP-Schnittstelle wollen wir auch unser Web-Portal für Test-Partner (und dazu Keycloak) im Internet publizieren. Erster Merge-Request für DNS-Namen ist angelegt, die weiteren Schritte (Pen-Test, ISGW, folgen später).
  • Martin: Merge-Request vorbereitet. Installation der Portal-UI, MW und Keycloak in der evu-test-umgebung laufen.
112
complete
Ausrollen der Änderungen aus dem Merge-Request.
  • Sean: Absicherung der Keycloak-Masken und f5-Konfiguration sollten mit Secure-Access-Services. Im Rahmen der ISGW-Vorgespräche.
113
complete
ISGW-Team anschreiben und Anforderungen klären.
  • Konstantin: Planung der Penetrationstest. Bestellsystem geht direkt auf NVI6 zu (Natalia/Harald/Sean in CC).
114
complete
NVI6 (Florian) anschreiben und Termine abstimmen.
  • Martin: brauchen wir einen anderen LB fürs Portal? Annahme: nein, die Unterscheidung nur im ISGW.
  • Netzwerk-Problem von EKS-Cluster zu ELB/Envoy→ siehe Termin 27.07.2021, Punkt 5

115 incomplete schaut sich das an. Analysen haben bisher nichts ergeben. Die E-Mail-Kommunikation an Martin+Konstantin weiterleiten. das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eOO-3

  • FYI, Nach ersten Erfahrungen mit SQS wollen wir unser Setup vereinfachen. Dazu verzichten wir künftig auf die dead-letter-queues und wahrscheinlich auch auf die FiFo-Queues (erfordert noch Absprache). → Erster Merge Request zum Hinzufügen der neuen Queues.
  • Künftige Termine: Im Bestellsystem haben wir jetzt einen 3-Wochen-Sprint. Um Kollision mit unseren Sprint-Terminen zu vermeiden würden wir alle folgenden Termine gerne um eine Woche verschieben, also nächste Abstimmungstermine am 31.8., 14.9. usw.
116
complete
verschiebt die nächsten Termine um eine Woche vor.
  • CNP-API für Self-Service.

117 complete gibt Martin Zugriff auf die API zum Ausprobieren.

  • Jetzt mit mehr Entwickler-Zugriff auf EKS wünschen wir uns ein Benutzer-Dashboard, könnt Ihr das was empfehlen? Wir können vermutlich selbst K8s-Dashboard oder k8dash starten...; aber bei der korrekten Konfiguration und einer OIDC-Anbindung (am besten an GitLab) würden wir lieber eine bestehende Vorlage nehmen anstatt alles selbst zu bauen und zu debuggen.
  • Sean: lens (wird aktuell beim Bestellsystem verprobt).
  • Martin: Session-Timeouts sind bei kubectl extrem kurz.
118
complete
prüft, ob ein Hochsetzen möglich ist.

Termin 10.08.2021

  • Service Mesh oder Ingress Controller: gibt es Neuigkeiten?
  • Service Mesh wird von neuem Kollegen implementiert, noch keine Termine
  • OIDC/Identity Provider: gibt es Neuigkeiten?
  • weiter in Arbeit, noch keine Termine
  • BBZ-API-Erreichbarkeit: gibt es Neuigkeiten?

104 complete untersucht das weiter

  • Pentest-Maßnahmen: gibt es Neuigkeiten?
  • TLS-Cipherliste am Loadbalancer
  • Zugriffsbeschränkung auf ISGW
  • HTTP-API-Pfade → ist in Envoy konfiguriert 

Termin 27.07.2021

  • Pentest-Maßnahmen seitens CNP prüfen
  • Nur ISGW soll auf Cluster-LB zugreifen dürfen (siehe ISGW-Doku für Port-Ranges) Nachtrag: einfacher Test mit Kommando curl -v https://evu-test-common-interface-bestellsystem-evu-test.cnp.comp.db.de/LIServices/LIHBMessage
  • TLS-Konfiguration in Cluster-LB härten => durch den oberen Punkt ist das vermutlich weniger kritisch, sollte außerdem ein allgemeines Thema für den LB sein.
  • Nur ausgewählte Pfade am LB durchlassen:

Das sollten "/LIServices/", "/LIMessageProcessing/" sein (mit Entwicklern gegenprüfen)

Nachtrag, 25.8.: in bestellsystem-evu-test haben wir jetzt einen festen Pod-Namen, da kann ich eine Kommandozeile zum Reproduzieren angeben:

120 complete mit Bitte um Fehlersuche im Envoy oder im AWS-Setup

  • Wir sehen immer wieder Probleme beim Starten von GitLab-Build-Pods in bestellsystem-dev.
  • DNS-Namensschema
  • Aktueller Stand Bestellsystem: wir vergeben für statische Deployments DNS-Namen nach Schema "--.cnp.comp.db.de" (z.Bsp. https://cnp-common-interface-bestellsystem-fargate.cnp.comp.db.de/)
  • Wir benutzen (künftig) auch pipeship für die CI-Pipeline, das vergibt temporäre Deploymentnamen aus Projekt- und Branch-Name (z.Bsp. common-interface-review-build-pipe-13ekrh) ==> damit wird es auch viele "unstrukturierte" Namen geben.
  • Wir verstehen den Wunsch noch das EKS-Cluster einzucodieren, aber zumindest in den temporären Build-/Test-Installationen bleibt uns praktisch kein Platz dafür. – Ist das wirklich notwendig, oder finden wir andere Wege dafür (vielleicht ein weiteres Element im Domain-Part, oder eine K8s-Annotation)?
  • ==> wird bei CNP weiter besprochen und refined

Termin 16.07.2021 (Sonderthema Monitoring)

  • Bedarf an einer Grafana-Instanz mit Schreibrechten für Entwickler.
  • Ideen des Bestellsystems sind hier dokumentiert (primär eigene Instanzen basierend auf MaaS).
  • Alternativvorschlag CNP: Zugriff auf die "Beta" Instanz des Grafana inkl. Schreibrechte 
93
complete
Infos zum Beta-Grafana verteilen
  • Input der Daten aus DBCS wünschenswert (falls nicht zu kompliziert)

94 complete , : prüfen zusammen ob Federation über Cortex-Endpoint funktioniert

  • Alert-Manager: In Arbeit bei CNP?
  • CloudWatch-Metriken für RDS/SQS/S3 in Grafana benötigt (Ein Muss für DevOps)
  • Zentrales Monitoring: ist primär ein CNP-Thema, keine unmittelbaren Projekt-Todos.

Termin 13.07.2021

  • Punkte aus den alten Terminen
  • Sean: http/2 sollte von AWS/K8s/ISGW unterstützt werden
  • Martin: Probleme mit Monitoring
87
complete
prüft es. Monitoring ist derzeit im Umbau.
  • Martin: ADR zu Aurora geschickt. Passt für CNP.
  • Aurora RDS ist die aktuelle Lösung.
  • Martin: Protokoll-Header X-Forward-Proto via Merge-Request hat noch nicht funktioniert.

88 complete prüft das

  • Natalia: Service-Mesh sollte besser als automatisierte Variante bereitgestellt werden.
  • Aktuelles Ziel: Bereitstellung App Mesh bis Mitte August
  • Abhängigkeiten
  • SSL für inter-service Kommunikation: ist nicht arg dringend
  • dynamische DNS-Einträge: recht dringend, CNP arbeitet an einem Fallback (für Verfahren ohne Mesh)

89 complete Wiedervorlage in 2 Wochen

  • Bestellsystem-Entwickler-Zugriff

  • Um mehr Wissen in unseren Teams zu verteilen würden wir gerne unseren Entwicklern mehr Zugriff gewähren.

  • im Teams-Kanal 'Bestellsystem' möchten wir Bishara Jaser und Frank Fk Thiele hinzufügen,

  • im GitLab-Repo 'bestellsystem-ops' würden wir denen auch Lese-Zugriff geben. Entweder der ganzen Gruppe Bestellsystem (falls das nicht "zu offen" ist), oder einzeln den Benutzern Bing Shi, Bishara Jaser und Frank Fk Thiele

  • S3 Object Lifecycle wir benutzen unsere S3-Buckets nur für temporäre Daten, die für SQS zu groß sind. Um die Verwaltung zu vereinfachen sollen die Daten nach bestimmter Zeit (in aktuellen Umgebungen nach 14 Tagen) gelöscht werden. → Merge Request in bestellsystem-ops

  • Konstantin: Pentest wurde durchgeführt.

  • Spannendste Ergebnisse und nächste Schritte besprechen.

  • fachliche Themen

  • Header-Handling im ISGW

  • Absicherung der Strecke ISGW → ELB

  • SecurityGroup/ACL damit nur der ISGW auf ELB zugreifen darf

90 incomplete einrichten ab 19.07 => danach Prüfung durch Entwickler, dass der interne Zugriff nicht mehr funktioniert.

  • prüfen, ob das für die EVU-Test-Umgebung ein Problem ist. Debug-Zugriff auf andere Umgebungen problematisch.
  • Annahme: interner Zugriff sollte nur über K8s-Proxy erfolgen. (Alternative wären 2 ELBs)
  • Folge-Aktionen
  • Bericht wird bis 17.7 erwartet
  • Verteilung an: CNP, NVI6 (db.netz.csac@deutschebahn.com)).
  • Freigabe durch NVI41
  • Plan: ab 1.8 soll EVU-Test extern verfügbar sein.
  • Konstantin: Status der Abstimmungen mit eBRS/MyNet/Kundenportal bzgl. der Einführung der SSO/MFA - aktuell nutzen wir als Workaround Keycloak. Falls keine Lösung von eBRS kommt, muss Keycloak (oder Alternative) zum Live-Gang durch das Projekt oder CNP  betrieben werden.
  • In Q3/Q4 wäre ein Pen-Test fürs Portal inkl. Keycloak  fällig.
  • 2 Freischaltungen notwendig: Portal + Login
  • evtl. schon mit der Keycloak-Alternative von CNP (siehe unten)
  • Vorlauf
  • ISGW ca. 1 Monat
  • Natalia: Keycloak braucht einen Support-Vertrag
  • Sean: arbeite gerade an einer AuthNAuthZ (A&A)-Lösung (als Alternative u.a. zu Keycloak)

91 complete : Wiedervorlage in 2 Wochen

92
complete
schickt Sean Doku und Gitlab-Links zu Keycloak zu: hier

Termin 29.06.2021

  • Diverses
  • Aktuelles Thema: gibt es Erfahrungen mit http/2? Unsere Entwickler haben das als Performance-Optimierung fürs Bestellportal identifiziert. Wir befürchten aber, dass dies von Proxies, LBs oder ISGW nicht unterstützt werden könnte.
75
complete
prüfen, ob das im ELB aktiviert werden kann.
  • Wechsel von RDS zu Aurora
  • Optionen: Aurora RDS vs. Aurora Serverless
76
complete
beim nächsten Termin ADR vorstellen
  • Stand EVU-Test Umgebung.
  • Erledigte Punkte
  • Weitere notwendige AWS-Dienste für EVU-Testumgebung bestellsystem-evu-test:  – Anmerkung Martin: ist inzwischen soweit erledigt, oder?
  • RDS-Datenbank (kleine Instanz so wie für bestellsystem-dev)
  • eigene Diskussion: im AWS-Kontext scheint Aurora der bessere Datenbank-Service zu sein, den würden wir gerne vertesten.
  • wir sind uns unsicher ob gerade dies eine gute Test-Umgebung ist, können wir da noch Monitoring für bekommen?
  • Meinung von Seite CNP? Habt Ihr Empfehlungen oder Präferenzen?
  • aktueller Status? –> laut bestellsystem-ops-Repo ist die RDS-Instanz eingerichtet, aber Martin hat noch kein Login-Passwort
  • die SQS-Zugriffsrechte stimmen noch nicht ganz, siehe Merge Request in bestellsystem-ops
  • DNS-Namen passen noch nicht, siehe Merge Request in bestellsystem-ops
  • Offen
  • Protokoll-Header X-Forward-Proto (muss https statt http sein).
77
complete
konfigurieren in ELB
  • Zertifikate für PEN-Tester.

78 complete  versucht Test-Zertifikate von RNE zu bekommen. Alternativ kann man die eigenen Zertifikate nutzen.

  • Roadmap Pipelines auf CNP (Migration von DBCS zu CNP)  – Was wäre noch nötig, um das Bestellsystem im PI21 (~Q3) nach CNP umzuziehen?
  • Management-API (kein Blocker fürs Bestellsystem) 
  • : Aktuell in Konzeption, PoC in Juli
  • separate (dezentrale) Management-APIs für Projekte notwendig. Lieferung bis Ende August möglich.
  • Die DNS-Einträge blockieren uns aktuell, weil automatische Tests per HTTPS so nicht funktionieren
  • Abhängigkeit zu Service-Mesh. Manuelle Bereitstellung (wie bei IFP) nicht empfohlen

79 complete  Wiedervorlage in 2 Wochen.

  • Workaround mit Cluster-local URLs funktioniert nicht für alle Use Cases (z.B. Cypress)
  • Alternative mit Ingress-Controller (ohne Service Mesh)

80 complete prüft bis 13.7

  • API-Zugriff um SQS-Queues anzulegen wäre hilfreich, aber nicht dringend notwendig (damit würden wir gerne localstack ersetzen)

  • siehe Management API oben.

  • Es wäre gut dafür im Cluster bestellsystem-dev neue Namespaces anzulegen (zur Info, in Abstimmung bei Martin und Sean):

  • build – dies ist dann der einzige Namespace in dem wir "Container als Root"-Rechte für Kaniko brauchen, sowie Zugriff zum GitLab-S3-Cache

  • ieu – unsere pre-prod Installationsumgebung, bräuchte dann SQS/S3 und RDS als Dienste

  • Last-/Performance-Test?

  • Fargate oder extra-Cluster? Fargate für die initiale LuP Entwicklung ok.

  • Keycloak-Betrieb auf CNP: Erfahrungen und Optionen.

  • dex statt Keycloak intern in CNP verwendet.

  • Siehe IAM-Portal und ADR

  • PoC in CNP geplant ab 5.7

  • Bestellsystem unterstützt mit Ressourcen (Martin und ein Entwickler/in aus Team 404).

Termin 22.06.2021

  • Anmerkung von : Web-Proxy-Policy webproxy.comp.db.de

  • nicht dringend, aber im Rahmen des EVU-Test-Setups aufgefallen: Anscheinend benutzt der Bahn-Web-Proxy verschiedene Policies für DBCS und CNP?

  • Test-Anfrage: https_proxy='http://webproxy.comp.db.de:8080' curl -v https://bestellsystem-commoninterface-test.dbnetze.com/history/heartbeat

  • lokal per VPN => timeout, ist OK, weder EVU-Test noch Proxy sind allgemein zugänglich

  • in DBCS mit webproxy.comp.db.de => HTTP 404 von ISGW, soweit OK, wenn das ISGW-Setup noch nicht fertig ist

  • in CNP mit webproxy.comp.db.de => curl: (56) Received HTTP code 403 from proxy after CONNECT, mit Header X-Squid-Error: ERR_ACCESS_DENIED 0

  • im Virtuellen Desktop (VDS) => curl: (56) Received HTTP code 403 from proxy after CONNECT, mit Header X-Squid-Error: ERR_ACCESS_DENIED 0

  • Ist also kein "Problem" mit CNP, sondern eher ein zusätzlicher Zugriff aus DBCS.

  • Nachtrag: aus Sicht Bestellsystem wünschen wir uns eine allgemeine Verfügbarkeit im internen Bahn-Netz (besonders auch per VPN und VDS), damit wir selbst einfach testen können

  • ISGW funktioniert noch nicht.

  • Endpunkt leitet nicht → Aktuell noch ein HTTP 404 → TODO  fragt bei ISGW nach ob der interne Endpunkt aufgelöst werden kann.

Custom SSL Zertifikat ist noch nicht gesetzt. → self signed cert → Zu klären ob das i.O. ist. → Erledigtbashaktueller Stand, Request mit RNE-Client-Zertifikattrue CONNECT bestellsystem-commoninterface-test.dbnetze.com:443 HTTP/1.1

Host: bestellsystem-commoninterface-test.dbnetze.com:443 User-Agent: curl/7.67.0 Proxy-Connection: Keep-Alive

GET /history/heartbeat HTTP/1.1

Host: bestellsystem-commoninterface-test.dbnetze.com User-Agent: curl/7.67.0 Accept: /

  • Mark bundle as not supporting multiuse
  • Vereinbarung war dass im header  X-Client-Cert header mit eingetragen → können wir erst testen wenn die Requests an unsere Services durchkommen

offener punkt ist der redirect von https auf http Nachtrag dazu: → Envoy sendet der Anwendung den falschen Header X-Forwarded-Proto: httpHTTP-Request Headertrue

68 complete können wir das in der Envoy-Config ändern? Als schnellen Fix für den EVU-Test könnten wir den Header immer überschreiben, weil wir von externen Clients nie HTTP-Verbindungen erwarten.

  • Wir brauchen eine Lösung für den Container-Image-Build.   nimmt   Hatten wir im März aufgeschoben, ist jetzt aber notwendig weil Kaniko nur mit root-Rechten im Container funktioniert; das kollidiert mit der OPA-Policy.
  • perspektivisch ggf. in seperatem namespace
  • Enovy Config wird nach dem PenTest umkonfiguriert, sodass wir explizit routes erlauben, statt zu verweigern. Hierfür werden die routes benötigt.

Nachtrag, ISGW-Termin 24.06.2021

Ergänze ich hier, weil das thematisch anschließt und einige offenen Fragen klärt.

  • HTTPS ist konfiguriert wie von uns angefragt
  • RNE-Server-Zertifikat für unsere CN
  • Client-Cert-Validierung gegen RNE-CA-Cert 'CA CCS 1'
  • Client-Cert-Daten werden base64-kodiert in den HTTP-Header X-Client-Cert eingefügt
  • es gab die Frage ob der Header bei jedem Request, oder nur beim ersten Request einer HTTPS/1.1 Session nötig ist. wir haben jetzt um jeden Request gebeten, – da gibt es künftig Optimierungsmöglichkeiten
  • Wie die Pen-Tester an Zertifikate kommen ist noch unklar → Kick-off-Termin
  • Die interne Erreichbarkeit der externen Domain ist schwierig und erfordert den Web-Proxy http://wwwproxy.tech.rz.db.de:8080
  • Zu Policy-Problemen/Fragen mit dem Proxy haben wir Alexander Perleth als Kontakt genannt bekommen.
  • weiterer Test: der webproxy.comp.db.de sperrt Zugriffe aus unserem EKS-Containern, aber der Proxy wwwproxy.tech.rz.db.de funktioniert
  • sehen wir da noch Handlungsbedarf?
  • Der aktuelle Fehler 404 wird durch einen falschen Hostnamen bzw. ein fehlendes Umschreiben des Hostnamen verursacht.
  • ISGW setzt auch in den internen Requests den HTTP-Header Host: bestellsystem-commoninterface-test.dbnetze.com
  • Der CNP-Envoy bzw. AWS-ELB kennt den Hostnamen nicht und antwortet mit 404
  • Korrektur dafür: den Hostnamen im CNP-Envoy einkonfigurieren --> wird von Sean eingetragen und mit Martin getestet

Termin 15.06.2021

  • Pen-Test für EVU-Testumgebung ist bestätigt Kick-off-Termin (1h, voraussichtlich 28. Juni), Sean wird eingeladen

  • EVU-Test

  • ISGW ist eingerichtet, interner Ziel-DNS fehlt noch

  • Deployment-Diagramm, bestellsystem-ops-Repo bei CNP und bestellsystem-deployment-repo bei Bestellsystem werden verlinkt

  • IFP-SQS-Tests

  • aktuell fehlen KMS-Zugriffsrechte → Merge Request in bestellsystem-ops

  • Klärung FIFO-/Standard-Queues in SQS und Umgebungen

  • Stand Service Mesh?

  • wird aktuell mit IFP implementiert,

  • für das Bestellsystem erst in Q4 realistisch

  • Roadmap Pipelines auf CNP – Das Bestellsystem plant im PI21 (~Q3) nach CNP umzuziehen

  • Die DNS-Einträge blockieren uns aktuell, weil automatische Tests per HTTPS so nicht funktionieren

  • eigener Namespace für build → Setup so wie in bestellsystem-dev mit EC2 und fargate

  • Martin und Sean besprechen das vor der PI-Planung

  • Bestellsystem-Testkonzept

  • Konzept im Bestellsystem-Confluence

  • technische Doku im Bestellsystem-Entwicklungshandbuch

  • nach dem EVU-Test werden wir das Web-Portal ins Internet bringen, dafür müssen wir einen Keycloak im Internet betreiben → Folgetermin

Termin 01.06.2021

  • Stand EVU-Test-Umgebung
  •  Wir haben im bestehenden Namespace bestellsystem-fargate einen neuen Service cnp-ifp-mock – für den hätten wir gerne DNS-Einträge um den im Review zeigen zu können.  SQS-Queues: evu-test-produktionsauftrag, evu-test-vertriebsauftrag. S3-Bucket: evu-test-vertriebsauftrag.  IAM-Role: bestellsystem-evu-test-sqs-access (mit read/write-Zugriff auf Queues und Bucket)
56
complete
wird eingerichtet. → bitte testen und ggf. Rückmeldung an  die Resourcennamen liegne im Teams Bestellsystem Channel
  • fehlende Zugriffsrechte → ist bei CNP in Arbeit

57 complete Lösung bis Montag 7.6 notwendig (notfalls ohne WebSSO) → kubeconfig wurde an  übermittelt

  • Monitoring funktioniert derzeit noch nicht für bestellsystem-evu-test

58 complete in Arbeit, benötigt bis 9.6 für die System-Demo des PI 20 →  Nachdem vergangende Woche die Nodegroup Resourcen gefixed wurden funktioniert nun auch wieder das Dashboard. Einige Dashboards für das bestellsystem-evu-test cluster werden erst etwas anzeigen wenn dort Workloads deployed wurden.

  • ISGW (und DNS) 

59 complete  :Domäne bestellsystem-commoninterface-test.dbnetze.com reserviert?

60
complete
ELB Probleme noch zu beheben. Ein ELB-Endpunkt für ISGW reicht aus.

66 incomplete Antrag wurde gestellt, jedoch wurde der Endpunkt im Antrag falsch ausgefüllt.  meldet sich sobald mehr Informationen verfügbar sind.

61 complete Zertifikat liegt vor. bei Bedarf bei Konstantin erfragen.

62
complete
Anforderung bzgl. Client-Zertifikate senden
  • PEN-Test vorbereiten

63 complete Anmeldung erfolgt sobald Natalia da ist

  • Wichtig: die Umgebung sollte zum 1.8 im Internet (nach dem PEN-Test) verfügbar sein.
  • Filterung der Routen für ISGW (Monitoring-Endpunkte, interne APIs) - wird im Service verprobt
  • AWS Aurora

64 complete  eine Aurora-Instanz zum Verproben

  • Pipelines
  • Bestellsystem hatte Austausch mit CDaaS-Team bzgl. Gitlab Agent. Es gibt ein Helm-Chart, der auch auf EKS benutzt werden darf.

Termin am 18.05.2021

  • Monitoring: Bestellsystem-Dashboards zeigen aktuell NO DATA an: 

37 complete prüft es und lässt es korrigieren (siehe 1.6.2021)

  • Aktuelle Bestückung des Clusters bestellsystem-dev mit 3 EC-Nodes
  • Reicht aktuell aus
  • Zusammenspiel von Plattform (CNP), Pipelines (MoQ-AP) und Anwendung (Bestellsystem)
38
complete
wird nach Natalias Rückkehr besprochen (siehe Themenspeicher, bzw. Termin am 8.6)
  • Umstellung des K8s-Logins auf Web-SSO:
  • es kann die selbe Nutzer-Liste wie für Dashboards genutzt werden
  • Erstmal keine Unterscheidung in Rechten
  • Service-Account für Gitlab-Runner
39
complete
kann User selbst anlegen, Anleitung bei Sean besorgen und dokumentieren
  • DNS-Publikation für Ingress-Controller
40
complete
fragt nach dem aktuellen Status (siehe 1.6.2021)

Termin am 11.05.2021

  • Ankündigung: künftig gibt es zwei Domains für prod und non-prod-Betrieb (cnp.comp.db.de und cnp-test.comp.db.de). Wenn es soweit ist wird das von Sean mit Martin koordiniert und im Bestellsystem-Deployment angepasst
  • schneller Check der letzten Agenda-Punkte
  • ISGW-Bestellung für EVU-Test, mit Größe S

41 complete  :wird im nächsten Sprint gemacht (siehe 1.6.2021)

  • Kurze Einordnung zur Roadmap Pipelines
  • Vorschlag: CNP-Distribution für den GitLab-Runner Wir haben jetzt einiges Trial-and-Error gebraucht um den GitLab-Runner für S3-Cache, für Fargate, und für non-privileged/non-root Pods zu konfigurieren. Für andere Projekte wäre es sicher hilfreich wenn es eine CNP-Default-Konfiguration gäbe. Zudem gibt es den Support-/Interne-Lizenzen-Graubereich dass wir gerade CDaaS-Setups und Container für CNP anpassen; auch da wäre ein CNP-Template hilfreich. => wird vermutlich an MoQ-AP abgegeben
  • Ankündigung: Der K8s-Login (aktuell bestellsystem-admin mit Token) wird auf Web-SSO umgestellt, Sean und Martin sprechen sich dazu ab

Termin am 04.05.2021

  • Bestellsystem-Benutzer zu den Bestellsystem-relevanten Dashboards hinzufügen (aktuell hat nur Martin Zugriff)
32
complete
schickt Sean eine Liste der Bestellsystem-Benutzer
33
complete
Gruppe Bestellsystem ergänzen
  • Dediziertes Cluster für EVU-Testumgebung bestellsystem-evu-test, 2x m5-large EC2
34
complete
legt Umgebung an
  • Service-Mesh Status: aktuell keine Neuigkeiten
  • Externer DNS-Name bestellsystem-commoninterface-test.dbnetze.com
35
complete
fragt bei Natalia nach
36
complete
liefert Feedback
  • PEN-Test kann (soll?) inzwischen DB-intern durchgeführt werden. Unklar ob damit Systel AppSec oder DB-Netz eigene Leute gemeint sind.
  • OPA Policies haben neulich den Kaniko-Build verhindert.
  • Künftig werden Policy-Änderungen vorab angekündigt
  • Container-Image Build - eine saubere Lösung steht noch aus. Evtl. kann hier MoQ-AP etwas bereitstellen.
  • Gitlab-Runner - vom wem wird dieser künftig bereitgestellt werden: MoQ-AP, CDaaS, CNP?

Termin am 27.04.2021

  • Neue Termin-Serie ab 4.5 9:15-9:45 alle 2 Wochen 
  • Bedarf für eine MacOS Instanz (mit Safari für Frontend-Tests) in der Cloud
  • Lässt sich die auf EC2 starten (https://aws.amazon.com/ec2/instance-types/mac/)?
  • Hürden: erfordert dedicated hosts und ist nur in Irland (eu-west-1) verfügbar.
  • => Region eu-west-1 ist K.O.-Kriterium, deshalb ist das Setup nicht möglich. (Wir werden also versuchen stattdessen einen BKU-Rechner zu bestellen).
  • Externe (Sub-)Domäne fürs Bestellsystem steht endlich fest (siehe BSQ-384): Wer kann sie im Service Manager Service Manager anlegen?

21 complete  : Auftrag über Natalia an TBF für den beschlossenen Namen 

  • Vorbereitung: EVU-Testumgebung und Pen-Test: dediziertes Cluster oder Namespace?
  • : schließen sich kurz
  • Deployment-Sicht auf das Bestellsystem
22
complete
Entwurf für 4.5.2021 → noch sehr vorläufig: https://git.tech.rz.db.de/-/snippets/613
  • Mit CI-Pipelines auf EKS brauchen wir auch mehr EC2-Ressourcen...  grobe Abschätzung: 3 × m5.xlarge (jeweils 4 vCPUs, 16 Gb RAM) -- für drei Anwendungs-Installationen (jeweils 1-2vCPUs und 4Gb RAM), 10 GitLab-Runner (jeweils 2-3vCPUs und 1-10Gb RAM), und 5-10 AT-Deployments (die review-Deployments könnten nach Fargate)
23
complete
erweitert die Node Group 

Wir sehen gelegentliche Fehler beim Starten von Pods.

K8s-Events: 

Das führt dann zum GitLab-Fehler: 

Können wir das verbessern?

Speziell in Fargate gibt es auch Probleme mit Ressourcen-Quotas, das liegt vermutlich an Verhalten oder Konfiguration der GitLab-Runner, erscheint aber nur gelegentlich (und ist dadurch schwer zu demonstrieren oder zu beseitigen):

  • Storage für Gitlab Cache: S3 bevorzugt
  • erledigt: Bucket ist angelegt und wird vom GitLab-Runner benutzt 
  • Nachfrage zu den ServiceAccount-Definitionen im bestellsystem-ops-Repo: sind die nur zur Info oder werden die irgendwann einmal eingespielt? Wir haben nämlich zusätzliche Einstellungen (imagePullSecrets), die wir dann ggf. einpflegen müssen.
24
complete
schaut sich das an. Prinzipiell kann das über MergeRequest beantragt werden.

Termin am 13.04.2021

  • Confluence für Mitschrift

13 complete Konstantin: Freischaltungen für Natalia + Sean

  • Serien-Terminverschiebung um eine Woche, ab 20.4

14 complete Natalia lädt ein

  • CNP-Umgebungen im Bestellsystem
  • Aktuell läuft eine PoC-Umgebung auf CNP, die fertige Docker-Images installiert, über einen Gitlab-Runner

15 complete : Bestellsystem wird um CNP-Monitoring erweitert (war schonmal drin)

  • Sean: S3-Queues müssen neu angelegt werden, da das Namensschema sich geändert hat

16 complete Sean geht auf Martin zu

  • Aktuell wird im Bestellsystem eine Build-Pipeline auf CNP aufgebaut

  • langfristigere Fragen:

  • automatische DNS-Einträge für Ingress

  • noch keine Terminaussage möglich

  • API-Zugang

  • frühestens in einem Monat

  • Info zu Service Mesh

  • siehe DNS-Einträge, Rollout am 27.4 geplant

  • Secret-Ablage im Bestellsystem

  • Gitlab-Runner legt sie im Kubernetes ab

  • Zugriffe aus VPN per HTTPS auf Anwendungen immer noch langsam (3-4 Sec)? 

  • scheinen sich gebessert zu haben

Termine am 01.03.2021, 16.03 und 30.03

Mitschrift

  • DNS-Einträge für neue Deployments/Ingresse (am 26.2. nochmal getestet; erfordert manuelle Schritte)
  • Sollte automatisch funktionieren --> kommt erst mit Service Mesh
  • Service Mesh: Recherche-Thema ganz am Anfang, wir wollen wissen was CNP anbietet bzw. plant​
  • Roadmap und Dokumentation: Ende März erste Service Mesh Version geplant (app.mesh)
  • Wie kann eine Lösung für REST-API Authentifizierung? Gibt es hierzu Infos?
  • Sean prüft das und schickt einen Vorschlag

5 incomplete (bis ca. 8.4)

  • Hängt von ausstehenden AWS Diensten ab (Ingress Controller)
  • In Q2 eher unrealistisch
  •  PEN-Test
  • Verschlüsselung/Authentifizierung
  • Offener Punkt --> kann PEN Test verhindern!
  • Natalia teilt Detaillsplanung wegen ISGW --> temp. Auch ohne PEN-Test möglich max. 2-3 Wochen --> vermutlich über CNP. Details klären.
  • (PEN-Test pro Service oder System, Beauftragung durch CNP, Vorlaufzeit bis zu 6 Wochen, ca. Ende Q2)
  • Kapa-Bel von IFP --> steht im März an
  • OPA für Autorisierung
  • Kann erst nach app.mesh kommen, frühestens im Juni für Projekte
  • Routing für Diskriminierungsfreiheit
  • Analog KommBau
  • Interne Adresse gesperrt (über Whitelist)
  • Keine Auswirkung auf Betriebsdienste
  • Anhebung des Monitorings auf die nächste Stufe --> vom demo/PoC zum Regelbetrieb
  • Heraufstufen der Umgebung

6 complete zwischen 15. und 25. März möglich, wird seitens CNP gemacht

  • Erstmal weiterhin ein Cluster-Admin-Account fürs Bestellsystem
  • falls wir ein Deployment ohne Fargate haben, dann auch Anwendungs-Logdaten in deren Grafana 

Wird mit dem Heraufstufen der Umgebung voraussichtlich gelöst

Wann geht Logging mit Fargate?

Erfordert einen Log-Forwarder über Dateien und eigenen Sidecar-Deployment (promtail-agent)

Alternativ warten auf AWS-Feature --> wird von Bestellsystem derzeit bevorzugt

SQS-Zugriffsrechte (ist in Arbeit, Maximilian war krank)

7 complete

Ist gerade in Arbeit

hybrider EKS-Namespace mit EC2 (für GitLab-Jobs) und Fargate (für skalierbare Installationen)

Martin schickt die Anforderungen an eine neue EC2 Instanz, CNP macht es zusammen mit der Heraufstufung (ebenfalls 15-25.03)

Reifegrad MoQ-AP Integration --> gibt es noch offene Punkte (insb. Privileged Mode)

Es kann in derselben Bestellsystem-Umgebung bei CNP laufen

Natalia kann das Wissen sharen (Betriebsstellen-Service) --> Austausch zwischen Projekten muss über MoQ-AP laufen

Privileged mode noch seitens MoQ-AP benötigt --> ist kein dringendes Problem

Vault vs AWS Secret Manager

Vault wird von Bestellsystem nicht benötigt

Wichtig sind Kubernetes Secrets

AWS Secrets Manager als Vorgabe

Regel-Termin alle 2 Wochen

8 complete

Natalia lädt ein

Reference in New Issue View Git Blame Copy Permalink