This commit is contained in:
2025-02-03 09:13:29 +01:00
parent 13184d1c6e
commit edaee1db5a
5 changed files with 9 additions and 8 deletions

View File

@@ -4,7 +4,7 @@
\section{Problemstellung}
In der Arbeitsumgebung des Partnerunternehmens besteht zum Zeitpunkt der Themenfindung der hier beleuchteten Arbeit kein
Management für Secrets und Logindaten zwischen Entwickler*innenn. Logindaten zu den Projekten des Unternehmens liegen schlicht in einem \ac{1P}-Vault.
Management für Secrets und Logindaten zwischen Entwickler*innen. Logindaten zu den Projekten des Unternehmens liegen schlicht in einem \ac{1P}-Vault.
\ac{1P} ist der vom Unternehmen verwendete Passwortmanager. Auf diesen Vault haben sämtliche internen Entwickler*innen Zugriff, jedoch keine externen Entwickler*innen.
Das ist so, weil anderenfalls dLesezugriff auf sämtliche Einträge dieses Vaults gegeben werden müssten.
\ac{1P} unterstützt keine Freigaben einzelner Einträge an andere Nutzer, ohne diese Einträge in einen eigenen Vault zu kopieren.

View File

@@ -7,7 +7,7 @@ Ziel ist es, eine Umgebung zu schaffen, in der beliebigen Entwickler*innen besti
\ac{1P}-Einträge zugewiesen werden können.
Der Pflegeaufwand sollte hierbei überschaubar bleiben.
Das heisst, dass z.B. ganze Gruppen von Einträgen Entwickler*innen zugewiesen werden können.
Wenn z.B. einem Projekt viele Einträge zugeordnet sind, sollten diese idealerweise mit einer einzigen Configzeile
Wenn z.B. einem Projekt viele Einträge zugeordnet sind, sollten diese idealerweise mit einer einzigen Konfigurationszeile
einem*r Entwickler*in zugeordnet werden können.
Außerdem sollte eine Möglichkeit ausgearbeitet werden, um \ac{1P}-Einträge in Ansible auszulesen,
damit keine Secrets mehr in den beiliegenden Konfigurationsdateien stehen, die das Freigeben