Ist es schlecht, Sudo von Jenkins zu verwenden?

Ich verwende das Publish Over SSH-Plugin , um meine Apps Jenkinsin verschiedenen Umgebungen bereitzustellen. Einige Bereitstellungsjobs führen Umgebungsvorbereitungen durch, z. B. das Beenden und Neustarten des App Server-Systemdienstes. Einige dieser Befehle erfordern sudo.

Ich bin nur neugierig, ob es eine schlechte Sicherheitspraxis sein kann, sudo für Jenkins-Jobs zur Remote-Veröffentlichung und -ausführung zu benötigen. Sollten wir die Sicherheitsrichtlinie auf dem Zielhost ändern, damit die erforderlichen Funktionen ohne sudo ausgeführt werden können?

Nein, es ist wirklich eine gute Sicherheitspraxis für sudo, wenn Sie Berechtigungen auf höherer Ebene benötigen. Dies ist der Grund, warum die meisten Distributionen die Standardanmeldung verbieten und Sie dazu zwingen, sudo suanstatt nur zu tippen. suSie möchten Sie dazu ermutigen, sudo aus Sicherheitsgründen zu verwenden. Es gibt nur wenige Gründe dafür:

• Prüfung. Wenn Sie sudo verwenden, zeichnet das System auf, wer sudoed hat und welchen Befehl sie ausgeführt haben. Dies fügt forensisch viel hinzu, wenn Sie zurückgehen und herausfinden müssen, was passiert ist - um Schuld zuzuweisen, schändliche Aktivitäten zu fangen oder nur zur Fehlerbehebung (was zum Teufel ist letzte Nacht um 19 Uhr passiert, bevor dieser Server AWOL wurde?).

• Sudo Regeln. Nur weil ein Benutzer etwas mit eskalierten Berechtigungen ausführen muss, bedeutet dies nicht, dass er alles mit eskalierten Berechtigungen ausführen muss. Wenn Sie su verwenden oder einen Benutzer zum Rad hinzufügen, kann ein Benutzer alles tun . Mit sudo ist es jedoch möglich anzugeben, was Benutzer mit Befehlsaliasen tun können und was nicht , wodurch Platzhalter verwendet werden können, wodurch flexible Regeln ermöglicht werden, die Benutzern das Recht einräumen, einige Befehle zu verwenden, andere jedoch nicht.

• Härten. Es ist möglich, root zu deaktivieren. Wie in, in jeder Hinsicht existiert es nicht und ist nur im Einzelbenutzermodus nützlich / verwendbar - erfordert einen Neustart eines Servers (und der einzige Grund, warum dies zulässig ist, ist die Kennwortwiederherstellung). sudo sufunktioniert nicht mehr. Dies erfolgt durch Setzen der Root-Shell auf / bin / nologin. Dies ist eine großartige Möglichkeit, um viele Sicherheitslücken bei der Root-Eskalation zu vermeiden. Dies setzt natürlich voraus, dass Sie das obige Aufzählungszeichen ordnungsgemäß verwenden (und Sie können einem bestimmten Administratorbenutzer weiterhin alle Berechtigungen erteilen, obwohl dies Ihre Sicherheitslage untergräbt).

Diese Dinge sind natürlich nur ein Teil Ihres Sicherheitsmodells. Wenn Sie beispielsweise keine Benutzer mit vollständigen Administratorrechten haben (und manchmal sogar dann), kann Ihr Benutzer möglicherweise Protokolle und den Verlauf löschen (wahrscheinlich auch) - es sei denn, Sie verwenden einen Protokollserver und ein Syslog, um Protokolle off-box zu versenden. Dann gibt es keine Möglichkeit, diese Katze wieder in die Tasche zu stecken. Wenn Sie eine zentrale Authentifizierungsverzeichnisstruktur verwenden, kommt dies natürlich wieder ins Spiel: Wenn ich ein Konto kompromittiere, wird es auf allen Servern in der Organisation kompromittiert - wahrscheinlich auch auf Ihrem Protokollserver.

Kurz gesagt, Sicherheit ist kompliziert, aber sudo ist ein großartiges Werkzeug für die Architektur einer sicheren Umgebung, und mehr Menschen sollten es in vollem Umfang nutzen.

Unabhängig davon, ob Sie Remote- sudooder Remotezugriff auf etwas zulassen , das SUID rooteine ziemlich ähnliche Angriffsfläche hat. Ich würde sudoin der Kette bleiben , weil Sie damit die Befehle leicht einschränken können und eine Protokollierung haben, die von entscheidender Bedeutung ist, wenn Sie die Dinge später überwachen müssen. sudohat auch eine viel längere Geschichte in der Produktion. Etwas anderes zu tun hat weniger Geschichte und höhere Veränderungen unangenehmer Überraschungen.

Es gibt noch andere Dinge, die Sie tun können, um dies sicherer zu machen:

• straffen ssh
• Lassen Sie die Neustartbefehle nur für einige bestimmte Benutzer zu, einschließlich eines für Jenkins
• Erlaube nur Anmeldungen für diese spezifischen Benutzer von allen internen IPs oder nur Jenkins und Jump-Box-IPs
• Speichern Sie Protokolle auf Remote-Boxen, damit sie nicht verfälscht werden können