Wie kann ich mit Juju mehrere Administratoren verwalten?

Ich verwalte einige Bereitstellungen mit Juju. Ich bin jedoch keine Insel, ich habe Mitarbeiter, die auch gemeinsam genutzte Umgebungen verwalten möchten.

Ich weiß, dass ich die folgende Strophe verwenden kann ~/.juju/environments.yaml, um Menschen Zugriff auf meine Juju-Umgebung zu gewähren:

authorized-keys: [and then put their ssh IDs in here]

Welche anderen Best Practices stehen zur Verwaltung mehrerer Umgebungen mit mehreren Systemadministratoren zur Verfügung?

Juju ist derzeit wirklich nicht für mehrere Administratoren optimiert. Insbesondere einige der Sicherheitsprobleme , die derzeit in Juju auftreten, werden bei der Arbeit mit mehreren Administratoren deutlicher. Mit einigen Einschränkungen kann dies jedoch eine nützliche Option für eine vertrauenswürdige - und daher wahrscheinlich kleine - Gruppe von Administratoren bleiben.

Schauen wir uns vor diesem Hintergrund die relevanten Konfigurationselemente in der ~/.juju/environment.yamlDatei an.

Das authorized-keysElement wird im Umgebungs-Bootstrap verwendet, um die öffentlichen SSH-Schlüssel für den Ubuntu-Benutzer auf dem Bootstrap-Knoten (Computer 0, auf dem ZooKeeper ausgeführt wird) und allen anschließend bereitgestellten Knoten zu definieren. Listen Sie einfach einen autorisierten öffentlichen Schlüssel pro Zeile auf. Es wird wie folgt aussehen:

authorized-keys: |
    ssh-rsa AAAblahblahZZZZ user@domain
    ecdsa-sha2-nistp256 AAAAfoobarZZZZ= user2@domain

Dieser Ansatz ist der Verwendung von authorized-keys-path- oder seiner Standardeinstellung ( ~/.ssh/) - vorzuziehen, die nur für einen Administrator geeignet ist, da Sie dann SSH-Schlüssel freigeben müssten (tun Sie das nicht!). Einfach ausgedrückt ist dies nur eine Einschränkung der authorized-keys-pathImplementierung.

Als Nächstes definieren Cloud-Anbieter ihre spezifischen Sicherheitsanmeldeinformationen, die Juju dann verwendet. Schauen wir uns als Beispiel EC2 an, insbesondere AWS. Für AWS werden zwei Schlüssel verwendet, um den Zugriff zu bestimmen: access-keyund secret-key, entsprechend den Umgebungsvariablen AWS_ACCESS_KEY_IDund AWS_SECRET_ACCESS_KEY(dies sind die Standardeinstellungen, wenn sie nicht in der Konfigurationsdatei angegeben sind). Die Herausforderung für eine Umgebung mit mehreren Administratoren - oder sogar für eine Umgebung mit nur einem Administrator - besteht darin, dass diese Informationen in ZooKeeper kopiert werden und im ZK-Knoten leicht sichtbar sind /environment. Siehe Juju- Fehler Nr. 907094 .

Im AWS-Beispiel kann ein gewisses Maß an Kontrolle über Ihre Zugriffsschlüssel mithilfe der häufig gestellten Fragen zu AWS Identity and Access Management (suchen Sie danach) bereitgestellt werden. Derzeit gibt es jedoch keinen Mechanismus, um einem bestimmten Administrator eine genauere Kontrolle zu ermöglichen eine Juju-Umgebung.

Ein zusätzliches Muster, das in unserer eigenen Verwendung, insbesondere beim Testen, zu sehen ist, ist erwähnenswert: eine Juju-Umgebung ("Steuerung"), die auf einem bestimmten Knoten eingerichtet wurde, um andere Juju-Umgebungen zu steuern; Setzen Sie einfach den Juju-Charme ein , um dies einzurichten. Als Konfigurationsoption wird die environment.yamlzu verwendende Option verwendet. Zusätzliche Administratoren können später als ubuntuBenutzer autorisiert werden, indem ihre Schlüssel manuell hinzugefügt werden ~ubuntu/.ssh/authorized-keys.

Dies ermöglicht es einem einzigen Punkt, einige dieser Probleme zu lösen und gleichzeitig die Kopfschmerzen zu minimieren. Es wird nichts unternommen, um einige der zuvor erwähnten Sicherheitsbedenken auszuräumen - Sie müssen immer noch ein einigermaßen tiefes Vertrauen in Ihre anderen Administratoren haben.

Juju RESYNC wird environments.yamlan den ZK - Knoten /environmentauf die Verwendung von bestimmten Befehlen ( juju add-unit, juju constraints-get, juju constraints-set, juju deploy, juju terminate-machine). In der Praxis wird dies nicht besonders nützlich sein - abgesehen von der tatsächlichen beabsichtigten Verwendung unterstützender Einschränkungen. Dies kann jedoch dazu beitragen, die Notwendigkeit zu minimieren, Dateien mit autorisierten Schlüsseln zu aktualisieren, da alle neu bereitgestellten Computer nach der Synchronisierung dies erhalten. Sie sind dann nur für die Aktualisierung früher bereitgestellter Computer verantwortlich.

Während ich in diesem Punkt bin, ist es erwähnenswert, wie und wo in ~ubuntu/.ssh/authorized-keystatsächlich verwendet werden:

• Mit zwei Ausnahmen verwenden alle Juju-Steuerbefehle einen SSH-Tunnel zur ZooKeepeer-Instanz, um Informationen aus der Juju-Umgebung zu verwalten oder nachzuschlagen. ( juju bootstrapund arbeiten juju destroy-environment direkt mit der zugrunde liegenden Cloud-Provider-API.) Sie müssen also auf jeden Fall die authorized-keys0 auf dem Computer auf dem neuesten Stand halten.

• juju sshund juju scpaktivieren Sie die direkte Arbeit mit einem Computer, und dieser muss über den aktuellen Stand verfügen authorized-keys, den Sie im Fall mehrerer Administratoren aktualisieren müssen. Diese Befehle verwenden standardmäßig den ubuntuBenutzer auf dem Zielcomputer.