web-dev-qa-db-ja.com

GitLab Pipelinesを使用したゼロ配備の場合-どのようなUNIXユーザーですか？

ウェブサーバーにゼロ配備戦略を実装したい。

私の最初の試みは、そのための特定のユーザー（デプロイヤー）を作成することでした：

# Create user deployer
Sudo adduser deployer
# Give the read-write-execute permissions to deployer user for directory /var/www
Sudo setfacl -R -m u:deployer:rwx /var/www

GitLabと this または this のようないくつかのチュートリアルを使用して、デプロイメントのプロセスを自動化しようとします。

しかし、ユーザーdeployerが特定のコマンドを実行するためにSudo権限を必要とするため、行き詰まりました。

さて、これは問題になるのでしょうか？私はgitlabにユーザーデプロイヤーに秘密のsshキーを与えているので、gitlabはサーバーに接続できます。

理論的にはgitlabがハッキングされる可能性があるため、私のサーバーもハッキングされるからです。

どう思いますか？またはリスクが非常に小さいので、心配する必要はありません。

sshwebserverunix
1
Shadrix

基礎

はい、サーバーのアクセス認証情報をGitlabに保存していて、Gitlabがハッキングされた場合、サーバーがハッキングされる可能性があります。アプリケーションをデプロイしているユーザーがrootアクセスを必要とする場合、gitlabにrootアクセスを与える以外に選択肢はありません（またはrootアクセスが不要になるようにアプリケーションを調整します）。

ユーザーアクセスレベル

Gitlabにサーバーへのrootアクセスを与えることについて特に懸念しているようです。それは確かにすべき可能であれば避けられますが、これは必ずしも最大の懸念事項ではありません。結局のところ、サーバーが行うのはアプリケーションのホストだけである場合、デプロイヤーユーザーとして侵入した人はすでに興味のあるすべてのものにアクセスできます。その時点で、ユーザーをrootにしても、それほど危険ではありません。

次のステップ

理想的な世界では、それはとにかく「サーバー」の問題ではないでしょう。たとえば、専用サーバーでどこかで実行している場合、rootが危険にさらされるのは確かに困難です。ただし、さらに一歩進んで、（たとえば）DockerイメージからプロビジョニングされたVPSまたはKubernetesクラスターを使用している場合、いずれかの「サーバー」が危険にさらされることはそれほど面倒ではありません。侵害の原因となった根本的な問題を修正し、新しい「サーバー」に再デプロイするだけです。明らかに、違反は常に悪いことであり、私は別の言い方をするつもりはありませんが、適切に実行されたインフラストラクチャでは、「サーバー」に対する懸念がはるかに少なくなるということが重要です。

Gitlabにアクセスキーを配置する必要がありますか？

Gitlabアカウントが危険にさらされるリスクが心配すべきかどうかは、あなたしか答えられない質問です。ここに、あなたが自問する必要のある質問があります。「私のデプロイメントを自動化することの利点は、サーバーが危険にさらされる追加のリスクに見合う価値があるのか​​？」

これは事実上、単純なリスク評価です。もちろん、答えるのが難しい妥協の可能性を知る必要があると答えるには。ただし、明確にするために、ハッキングされているGitlab自体は（IMO）、ユーザー側のセキュリティミスよりも可能性が低いです。

  1. Gitlabで強力な一意のパスワードを使用していることを確認してください
  2. 安全な2FAアカウントを有効にする
  3. CI/CDスクリプトのシークレットの保存に関するベストプラクティスに従ってください。

また、これはサーバーが危険にさらされる可能性のある多くの可能な方法の1つにすぎないことにも注意してください。 CI/CDパイプラインが十分に保護されていることを確認することは1つの優先順位にすぎません。同時に、サーバー上で開いているFTPサーバーを実行している場合、またはアプリケーションがアプリケーションのセキュリティの基本に従っていない場合は、さらに大きくなります。揚げる魚。

しかし結局のところ、この追加の自動化ステップがリスクの増加に値するかどうかを判断できるのはあなただけですあなたにとって。

2
Conor Mancone