꼭두각시 보안 및 네트워크 토폴로지

배경:

나는 마침내 21 세기에 참여하고 꼭두각시를 볼 시간을 따로두고 있습니다.

오늘날 우리는 사무실에 내부적으로 보유 된 저장소의 모든 서버 구성을 버전 제어합니다. 업데이트가 필요한 경우 변경 사항이 repos에 다시 체크인되고 해당 머신으로 수동으로 푸시됩니다. 이는 일반적으로 SFTP가 원격 시스템으로 전송 한 다음 관련 권한으로 쉘에서 파일을 제자리로 이동시키는 것을 의미합니다.

따라서 꼭두각시가 이미 가지고있는 것의 단순하면서도 놀라운 확장이 되길 바랍니다.

이제 저는 현재 우리가 합리적으로 안전해야하는 프로세스를 고려합니다. 내부 네트워크가 데이터 센터의 공용 네트워크보다 항상 더 안전하다는 가정하에.

• 프로세스는 항상 한 가지 방법입니다. 변화는 안전한 환경에서 안전하지 않은 곳으로 이동하며 결코 다른 방향으로 돌지 않습니다.

• 마스터 스토어는 가장 안전한 장소에 있습니다. 구성을 훔치거나 악의적 인 수정 사항을 보내면 손상 될 위험이 크게 줄어 듭니다.

의문:

내가 Puppet 서버 / 클라이언트 모델에 대해 이해 한 것은 클라이언트가 서버에서 직접 업데이트를 폴링하고 풀다운한다는 것입니다. 트래픽이 SSL 래핑되어 있으므로 가로 채거나 스푸핑 할 수 없습니다. 그러나 Puppet 서버는 공개 위치에서 호스팅해야하기 때문에 현재 수행하는 작업과 다릅니다. 중앙에서 또는 우리가 유지 관리하는 각 데이터 센터 사이트마다 하나씩.

그래서 궁금합니다.

• 푸시에서 풀로의 변경에 대해 불필요하게 편집증입니까?

• 모든 정보를 공용 네트워크에 중앙에 저장하는 데 불필요하게 편집증이 있습니까?

• 다른 사람들은 어떻게 여러 네트워크를 유지합니까? 각 사이트마다 별도의 서버입니까?

업데이트 30/07/09 :

내 다른 큰 관심사 중 하나는 두 대의 컴퓨터를 신뢰해야한다는 것입니다. 꼭두각시 마스터는 방화벽으로 보호되고 보안이 유지됩니다. 그러나 청취 서비스를 제공하는 모든 공용 컴퓨터에서도 특정 크기의 공격 표면을 가지고 있습니다.

아마도 마스터가 퍼펫 클라이언트 중 하나에서 파일을 업데이트 할 수있는 권한이 있다면 타협으로 인해 모든 클라이언트가 타협하게됩니다. "왕국에 왕"이라고 말해.

• 그 가설이 맞습니까?

• 완화 할 수있는 방법이 있습니까?

때로는 모듈에 변수에 비밀번호를 저장하기 때문에 수동으로 구성을 완료하지 않고도 응용 프로그램을 배포 할 수 있기 때문에 퍼펫 저장소를 퍼블릭 서버에 배치 할 수 없습니다. 그렇게하면 꼭두각시 마스터를 공격하면 모든 서버에서 다른 모든 응용 프로그램의 일부 응용 프로그램 또는 db 암호를 얻을 수 있습니다.

그래서 내 puppetmaster는 사무실 개인 네트워크에 있으며 서버에서 puppetd 데몬을 실행하지 않습니다. 배포해야 할 때 개인 네트워크에서 서버로 ssh를 사용하여 터널을 만들고 원격으로 puppetd를 호출합니다.
트릭은 원격 터널 및 퍼펫 클라이언트가 꼭두각시 마스터에 연결되도록 설정하는 것이 아니라 http 연결 을 수락 하고 개인 네트워크의 퍼펫 마스터 서버에 연결할 수 있는 프록시로 설정하는 것 입니다. 그렇지 않으면 호스트 이름이 인증서와 충돌하여 퍼펫이 풀을 거부합니다.

# From a machine inside privatenet.net :
ssh -R 3128:httpconnectproxy.privatenet.net:3128 \
    -t remoteclient.publicnetwork.net \
    sudo /usr/sbin/puppetd --server puppetmaster.privatenet.net \
    --http_proxy_host localhost --http_proxy_port 3128 \
    --waitforcert 60 --test –-verbose

그것은 나를 위해 작동, 그것이 당신을 도울 희망

우리는 사무실과 콜로라는 두 사이트를 가지고 있습니다. 각 사이트에는 자체 puppetmaster가 있습니다. 다음 구조로 svn 저장소를 설정했습니다.

root/office
root/office/manifests/site.pp
root/office/modules
root/colo
root/colo/manifests/site.pp
root/colo/modules
root/modules

각 사이트의 모듈 디렉토리는 최상위 레벨 모듈 디렉토리로 돌아가는 svn : externals 디렉토리입니다. 이는 이들이 정확히 동일한 모듈 디렉토리를 공유 함을 의미합니다. 그런 다음 우리가 작성하는 대부분의 클래스가 모듈 디렉토리 아래에 있고 두 사이트에서 모두 사용되는지 확인합니다. 이것은 우리가 일반적으로 생각하고 강의를 특정 사이트에 묶지 않도록 강요한다는 좋은 이점이 있습니다.

보안과 관련하여 방화벽 뒤에 꼭두각시 마스터 (및 나머지 네트워크)를 호스팅하므로 구성을 중앙에 저장하는 것에 대해 걱정하지 않아도됩니다. 꼭두각시 마스터는 신뢰하는 호스트에게만 설정을 보냅니다. 분명히 그 서버를 안전하게 유지해야합니다.

나는 당신의 편집증이 얼마나 필요한지 판단 할 수 없습니다. 그것은 당신의 환경에 달려 있습니다. 그러나 기존 구성의 두 가지 주요 사항이 여전히 적용될 수 있다고 확신 할 수 있습니다. puppetmaster가있는 곳이면 어디에서나 보안 환경 (사무실의 저장소)에서 보안 수준이 낮은 환경으로 변경 사항을 전달할 수 있습니다. SFTP에서 여러 서버로 프로세스를 변경하고 수동으로 puppetmaster에 SFTP에 배치 할 파일을 배치하고 Puppet이 파일을 배포하여 올바른 위치에 배치하도록합니다. 마스터 저장소는 여전히 저장소이며 위험은 완화됩니다.

나는 밀거나 당기는 것이 다른 모델보다 본질적으로 더 안전하다고 생각하지 않습니다. Puppet은 전송 중에 구성을 보호하고 클라이언트와 서버를 모두 인증하여 양방향 트러스트가 있는지 확인합니다.

여러 네트워크의 경우 중앙 마스터에 대한 클라이언트 역할을하는 각 위치에 위성 puppetmaster가있는 중앙 "마스터"puppetmaster로 처리합니다.

한 가지 디자인 방식은 각 시스템 사이트에 로컬로 puppetmaster를 배치하고 배포 도구를 사용하여 puppetmaster에 변경 사항을 적용하는 것입니다. (git hooks와 함께 git을 사용하면 작동 할 수 있습니다).

꼭두각시 네트워크 트래픽은 내부적 인 것일 뿐이므로 공용 네트워크에서 서비스를 수신하는 것에 대한 걱정을 막을 수 있습니다.

매니페스트를 각 서버로 푸시하고 퍼펫 클라이언트가 매니페스트를 구문 분석하고 관련 구성을 적용하도록 할 수도 있습니다.

당신이 "외부"라고 말하지만, 나는 임의의 사람들이 당신의 꼭두각시 마스터에 연결해야한다고 의심합니다. 언제든지 VPN을 믹스에 넣을 수 있습니다. 내 친구가 한 번 "연결이 안전한 경우 프로토콜의 보안에 대해 걱정할 필요가 있습니까?" 나는 그 태도에 동의하지 않지만, 여분의 층은 결코 내 개인적인 편집증에 상처를 입히지 않으며 확실히 놀라운 일을합니다. 게다가 터널 터널 재미.

cfengine의 저자이자 대학 교수 (꼭두각시가 그 유산을 빚지고있는 것 같습니다) 인 Mark Burgess는 밀고 당기기에 관해 많은 글을 썼습니다. 그는 당김이 본질적으로 더 안전하다고 주장한다. cfengine 웹 사이트를 보면 17 년 동안 1 건의 네트워크 보안 사고 만있었습니다. 버지스는 풀 디자인 때문이라고 주장했다. 타협점은 불가피하다고 생각합니다. 나는 그 시점까지의 공격 경로에 대해 더 걱정할 것입니다.

원하는 경우 중앙 마스터없이 퍼펫을 실행할 수 있습니다. 내가 본 한 가지 방법은 git 저장소를 사용하고 태그가 사전 설정된 gpg 키 목록 중 하나에 의해 서명 된 경우에만 업데이트를 병합하고 배포하는 스크립트를 사용하는 것입니다. 사람들은 저장된 구성을 얻는 방법을 연구했습니다 (예 : 다른 서버에서 처리되는 리소스에서 중앙 서버에 nagios 모니터링을 설정하는 데 사용).

따라서 중앙 git 서버가 손상되면 다른 서버는 더 이상 업데이트를 적용하지 않습니다. gpg 키는 시스템 관리자 랩톱 또는 키를 취소하는 방법과 함께 있습니다.

http://current.workingdirectory.net/posts/2011/puppet-without-masters/ 에서 자세히 알아보십시오 .