touchups
This commit is contained in:
@@ -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.
|
||||
|
@@ -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
|
||||
|
Reference in New Issue
Block a user