%
% Chapter: Einleitung/Problemstellung
%

\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*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 Lesezugriff 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.
Würden diese manuell in einen eigenen Vault kopiert werden, müssten diese Einträge fortan redundant gepflegt werden. Das ist eine Fehlerquelle, die zu
asynchronen Einträgen führt. Außerdem ist das ein großer Arbeitsaufwand.
All das gestaltet das Einbinden von externen Entwickler*innen, wie z.B. Freelancer*innen, schwer.
\\
\\
Ein weiteres Problem ist, dass Secrets in Konfigurationsdateien, die firmeninternen Ansible-Scripten
beilegen, unverschlüsselt einsichtig sind. Das macht es zu einem großen Sicherheitsrisiko und somit
inpraktikabel externen Entwickler*innen Zugriff auf dieses Ansible-Repository zu gewähren.
Dieses Ansible-Repository ist jedoch zwingend erforderlich, um eine Entwicklungsungebung für
Firmenprojekte auf dem lokalen Rechner zu schaffen. Auch hier sind Lösungen für externe
Entwickler*innen zumeist unschöne Workarounds.
