Jenkins'ten sudo kullanmak kötü mü?


11

Uygulamalarımı farklı ortamlardan dağıtmak için Publish Over SSH eklentisini kullanıyorum Jenkins. Bazı dağıtım işleri ortam hazırlıkları yapar ve uygulama sunucusu sistem hizmetini durdurup yeniden başlatmak gibi şeyler yapar. Bu komutlardan bazıları gerekir sudo.

Sadece uzaktan yayınlama ve yürütme Jenkins işlerinde sudo gerektirmenin kötü bir güvenlik uygulaması olup olmadığını merak ediyorum. Gerekli ana bilgisayarların sudo olmadan gerçekleştirilmesine izin vermek için hedef ana bilgisayardaki güvenlik ilkesini değiştirmeli miyiz?

Yanıtlar:


6

Hayır, üst düzey ayrıcalıklara ihtiyacınız olduğunda sudo yapmak gerçekten iyi bir güvenlik uygulamasıdır. Çoğu dağıtımın varsayılan oturum açmayı yasaklaması ve sizi sudo suyalnızca yazmak yerine zorlamaya neden olmasının nedeni budur su- sudo'yu güvenlik avantajları için kullanmaya teşvik etmek isterler. Bunun birkaç nedeni vardır:

  • Denetim. Sudo yaptığınızda, sistem kimin sudoing yaptığını ve çalıştırdıkları komutu kaydeder. Bu, geri dönüp ne olduğunu anlamanız gerektiğinde adli olarak ekler - suçlama atamak, haksız faaliyetler yakalamak veya sadece sorun giderme amacıyla (bu sunucu AWOL gitmeden önce akşam 7'de ne oldu?)

  • Sudo kuralları. Bir kullanıcının yükseltilmiş ayrıcalıklarla bir şey çalıştırması gerektiğinden, her şeyi artan ayrıcalıklarla çalıştırması gerektiği anlamına gelmez . Su kullanmak veya tekerleğe kullanıcı eklemek, kullanıcının her şeyi yapmasına olanak tanır . Ancak sudo ile , joker karakterlerin kullanılmasına izin veren Komut Takma Adlarını kullanarak kullanıcıların neler yapabileceğini ve yapamayacağını belirlemek , böylece kullanıcılara bazı komutları kullanma ayrıcalıkları veren, ancak diğerlerine izin vermeyen esnek kurallara izin vermek mümkündür.

  • Sertleşme. Kökü devre dışı bırakmak mümkündür. Tüm niyetler ve amaçlar için olduğu gibi, mevcut değildir ve yalnızca tek kullanıcı modunda kullanılabilir / kullanılabilir - sunucunun yeniden başlatılmasını gerektirir (ve buna izin verilmesinin tek nedeni parola kurtarmadır). sudo suArtık çalışmıyor. Bu, root'un kabuğunu / bin / nologin olarak ayarlayarak yapılır . Bu da birçok kök yükseltme zayıflığını önlemenin harika bir yoludur. Bu, elbette yukarıdaki madde işaretini doğru bir şekilde kullandığınızı varsayar (ve yine de belirli bir yönetici kullanıcıya tüm izinleri verebilirsiniz, ancak bu, güvenlik duruşunuzu zayıflatacaktır).

Bunlar elbette güvenlik modelinizin sadece bir parçasıdır. Örneğin, tam yönetici ayrıcalıklarına sahip bir kullanıcınız yoksa (hatta bazen o zaman bile), günlükleri kutudan göndermek için bir günlük sunucusu ve syslog kullanmıyorsanız, kullanıcı günlükleri ve geçmişi silebilir (muhtemelen). O kediyi çantaya koymanın bir yolu yok. Tabii ki, merkezi bir kimlik doğrulama dizini yapısı kullanırsanız, o zaman bu tekrar devreye girer: Bir hesaptan ödün verirsem, muhtemelen günlük sunucunuz da dahil olmak üzere kuruluştaki tüm sunucularda tehlikeye atılır .

Kısacası, güvenlik karmaşıktır, ancak sudo güvenli bir ortam tasarlamak için harika bir araçtır ve daha fazla insan onu tam olarak kullanmalıdır.


7

İster benzer bir saldırıya uzaktan sudoveya uzaktan erişime izin verin , SUID rootbenzer bir saldırı yüzeyine sahip olursunuz. Ben tutacağını sudosize kolayca komutları sınırlandırmak sağlar ve daha sonra denetim şeyler gerekiyorsa hayati olacak günlüğü vardır çünkü zincirde. sudoayrıca üretimde çok daha uzun bir geçmişe sahiptir. Başka bir şey yapmak daha az geçmişe ve hoş olmayan sürprizlerin daha yüksek değişikliklerine sahip olacaktır.

Ancak bunu daha güvenli hale getirmek için yapabileceğiniz başka şeyler var:

  • hazırlan ssh
  • sadece yeniden başlatma komutlarına izin ver, bunlardan biri jenkinler için de dahil olmak üzere birkaç belirli kullanıcı için
  • yalnızca tüm dahili IP'lerden veya yalnızca jenkinlerden ve atlama kutusu IP'lerinden belirli kullanıcılar için oturum açmaya izin ver
  • günlükleri uzak kutularda depolayın, böylece

Aslında, ben sadece SSH iş yapılandırdı ve çalıştırmak istemiyordu sudo: "sudo: üzgünüm, sudo çalıştırmak için bir tty olmalı"
amphibient

1
Sen vermek gerekebilir seçeneği. Veya sudo'yu unix.stackexchange.com/questions/122616/… gibi ihtiyaç duymayacağına ikna edinssh-t
civcivler

Jenkins'ten çağrıldığında SSH'ye nasıl bir seçenek sunabilirim?
Ekim'deki ampütan

Bunun hakkında emin değilim. sudoBağlantının gösterdiği gibi düzenlemeyi denediniz mi?
civcivler

1
Uzak ana bilgisayardaki sudoers (SSH hedefi) tty gerektirmediği için Defaults requiretty
sudo'ları değiştirerek sudo'yu etkinleştirmeyi başardım
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.