Ansible - Private Git-Repositorys - Weiterleitung von SSH-Agenten im Vergleich zum Kopieren von privaten SSH-Schlüsseln

Ich habe vor kurzem angefangen, mit Ansible herumzuspielen und es scheint sehr schön zu sein. Ich habe nicht viel Erfahrung mit DevOps und musste nie wirklich mit komplexen Szenarien umgehen. Ich habe begonnen, mein Ansible-Playbook zu erstellen, um mein aktuelles Bereitstellungstool - Deployer PHP - zu ersetzen. Ich bin leider beim Klonen des Git-Repositorys festgefahren. Jetzt weiß ich, dass ich einen öffentlichen Schlüssel hinzufügen muss, um den Zugriff auf das Git-Repository zu ermöglichen, und hier kommt meine Frage.

Sollte ich die SSH-Agentenweiterleitung verwenden (auf diese Weise kann ich meine lokalen SSH-Schlüssel verwenden) oder sollte ich einen privaten SSH-Schlüssel (verschlüsselt, zur Quellcodeverwaltung hinzugefügt) in meinem ansible-Projekt speichern und ihn mit Ansible auf meinen Zielknoten kopieren? Ich weiß, dass die Frage sehr weit gefasst sein kann. Was mich also interessiert, sind die Auswirkungen beider Ansätze auf die Sicherheit.

Sie können auch in Betracht ziehen, die Datei mit Ihrem privaten SSH-Schlüssel mit Ansible Vault zu verschlüsseln.

Einige Links:

http://docs.ansible.com/ansible/latest/playbooks_vault.html

https://therealmarv.com/ansible-vault-file-handling/

https://www.calazan.com/how-to-deploy-encrypted-copies-of-your-ssl-keys-and-other-files-with-ansible-and-openssl/

Wenn Ihr Git-Repos ein privater Github ist, können Sie Github-Methoden verwenden (Bereitstellungsschlüssel sind sehr leistungsfähig).

Wenn Ihre Repos nicht auf Github gehostet werden oder keine schreibgeschützte Bereitstellungsschlüsselfunktion bieten, sind die beiden von Ihnen genannten Optionen beide wertvoll.

Single DevOps Typ

Wenn Sie die einzige Person sind, die an dem Projekt arbeitet, und Ihre Maschine / Maschinen die einzige sind, von der aus Sie ansible ausführen können (keine CD-Tools wie Jenkins und Freunde), können Sie sich für die Agentenweiterleitungsoption entscheiden: Es ist wahrscheinlich weniger möglich, dass Sie Vergessen Sie Ihren privaten Schlüssel unverschlüsselt.

Kleines Team

Wenn Sie ein Team von Personen sind, die an demselben Ansible-Playbook arbeiten, oder an mehreren Personen, die das Playbook ausführen, haben Sie beide Möglichkeiten:

• Behalten Sie die Option zur Weiterleitung von Agenten bei. Jeder Teamkollege führt das Skript von seinem Computer aus.

• Erstellen Sie ein Deployer-Schlüsselpaar, laden Sie den Pub-Schlüssel hoch und verschlüsseln Sie das Private mit Vault, wie von Berlin vorgeschlagen . Der Schlüssel ist verschlüsselt und der Umfang des privaten Schlüssels ist auf nur 1 oder wenige Repos beschränkt. Das Problem bei diesem Ansatz ist, dass Sie das Tresorkennwort jedes Mal drehen müssen, wenn ein Teamkollege das Team verlässt.

Ich würde meinen persönlichen privaten Schlüssel, der einen großen Umfang hat, niemals an einem möglicherweise unsicheren Ort ablegen. Die Tresorverschlüsselung ist so gut wie die Leute, die sie verwenden, und es gibt viele Schlüssel / Passwörter im Klartext da draußen :)

Sollte ich die SSH-Agentenweiterleitung verwenden (auf diese Weise kann ich meine lokalen SSH-Schlüssel verwenden)

Ja, das könnte eine Option sein

sollte ich einen privaten SSH-Schlüssel (verschlüsselt, zur Quellcodeverwaltung hinzugefügt) in meinem ansible-Projekt speichern und ihn mit Ansible auf meinen Zielknoten kopieren?

Nein

/server/823956/ansible-security-best-practices

Erlauben Sie für Server überhaupt keinen Root-Zugriff über ssh. Viele Audits machen sich darüber lustig.

Lassen Sie für Ansible jeden Administrator sein eigenes persönliches Konto auf jedem Zielserver verwenden und lassen Sie ihn mit Passwörtern sudo. Auf diese Weise wird kein Passwort zwischen zwei Personen geteilt. Sie können auf jedem Server überprüfen, wer was getan hat. Es liegt an Ihnen, ob persönliche Konten die Anmeldung über das Kennwort oder nur den SSH-Schlüssel zulassen oder beides erfordern.

Verwenden Sie zusammenfassend einen SSH-Schlüssel mit Kennwort. Lassen Sie jeden Benutzer seine eigenen SSH-Schlüssel verwenden. Erlaube niemals den Sudo-Zugang über ssh.

Sie können Ihren privaten Schlüssel unter einem Umstand erstellen: Wenn Sie Ihr Repository so konfigurieren, dass nur Lesezugriff für diesen bestimmten Schlüssel möglich ist, und Sie sich nicht darum kümmern, dass das Repository öffentlich lesbar ist. In diesem Fall können Sie Ihren privaten Schlüssel einfach speichern - natürlich einen Wegwerfschlüssel ohne Passphrase erstellen. Aber wie gesagt, nur wenn Sie mit dem öffentlichen Zugriff auf dieses Repository einverstanden sind.

Wenn dies nicht der Fall ist, stecken Sie wahrscheinlich beim SSH-Agenten fest. Es ist nicht ideal, wie rootes der Socket nehmen kann, aber wenn Sie sich in einer Art wohlwollender Umgebung befinden (dh kein angreifbarer Webserver in der Nähe), sollte es in Ordnung sein.