Command Center는 서버에 대한 액세스가 제한되어 있습니다.

Command Center는 서버에 대한 액세스가 제한되어 있습니다.

저는 이것을 자동화할 방법을 찾고 있습니다. 저는 다수의 Linux 서버를 가지고 있고 SSH를 통해 서버에 로그인하고 작업을 수동으로 실행할 필요 없이 그 서버에서 일부 스크립트를 실행할 수 있기를 원합니다.

서버에서 사전 정의된 특정 작업을 실행할 수 있는 통합 명령 센터를 원합니다.

이러한 요구를 충족할 수 있는 ansible과 같은 여러 도구가 있다는 것을 알고 있습니다.

하지만 또 다른 요구 사항이 있습니다. 사전 정의된 작업을 실행할 수 있도록 명령 센터를 제한하고 싶습니다.전적으로그게 다야. 따라서 명령 센터가 완전히 손상되면 공격자는 미리 정의된 작업만 수행할 수 있으며 명령 센터에 대한 SSH 액세스를 제공하는 솔루션은 이 요구 사항에 위배됩니다.

몇 가지 도구를 검색하고 사용해 보았지만 어느 것도 내 요구에 적합하지 않았습니다.

답변1

귀하가 발견한 바와 같이, 다른 사람이 구축한 솔루션은 고용주/조직이 부과한 요구 사항/제한 사항을 기반으로 사용 사례를 제공하기 위해 구축된 네트워크에 존재하는 문제를 해결하지 못합니다.

즉, 인터넷에서 솔루션을 복사하여 아키텍처에 붙여넣고 완벽하게 작동하도록 할 수는 없습니다. 요구사항/필요에 맞게 사용자 정의해야 합니다.

우리 모두는 이것을 배우는 과정을 겪습니다. 당신도 그것을 배우고 있습니다. 클럽에 오신 것을 환영합니다.

귀하의 경우 서버에서 변경/작업을 수행하는 솔루션의 일부를 처리하는 여러 구성 관리 제품군이 있습니다. Ansible, Chef, Puppet, Saltstack 등은 일반적으로 루트 액세스(직접 또는 sudo를 통해)를 통해 이 부분을 수행할 수 있습니다. 그러나 각 서비스에는 어떤 사용자가 전화를 걸 수 있는지에 대한 몇 가지 규정이 있을 수 있지만 정확히 원하는 작업을 수행하지는 않습니다.

그러나 이 계층 규제(제어)는 구성 관리 시스템과 함께 작동하는 다른 소프트웨어 제품군에서 처리할 수 있습니다. 예를 들어 Jenkins와 같은 CI/CD 플랫폼을 사용하여 Ansible 플레이북을 호출할 수 있습니다. Ansible이 권한 있는 액세스를 사용하여 필요한 자동화 작업을 완료하지만 Jenkins 작업자 시스템만 Ansible 플레이북을 호출할 권한이 있는 아키텍처를 상상해 보세요. Jenkins 구성은 플레이북을 실행할 수 있는 사용자를 제어합니다. 작업을 완료하고 누가 어떤 작업을 실행할 수 있는지 제어하는 ​​자동화된 작업을 얻을 수 있습니다. 이것콤비네이션Ansible과 Jenkins의 조합은 모든 보안 및 비즈니스 요구 사항을 충족할 수 있습니다.

이는 인프라/운영 작업 집합에 가깝기 때문에 소프트웨어 개발자가 사용자 지정 애플리케이션을 배포하는 데 사용하는 인스턴스와 별도의 Jenkins 인스턴스를 생성할 수 있습니다.

Ansible과 Jenkins여야 합니까? 아니요. 널리 사용되며 함께 사용하는 것을 상상할 수 있기 때문에 제안합니다. 다른 CI/CD 제품군이나 기타 구성 관리 제품군에 더 익숙하다면 이를 사용할 수 있습니다. 제가 제안하고 싶은 아이디어는 두 개 이상의 소프트웨어 제품군을 빌딩 블록으로 결합하여 모든 요구 사항에 맞는 완벽한 솔루션을 만드는 것입니다.

관련 정보