요리사 : 암호화 된 데이터 백, 암호화 키 보호


8

Chef에 암호화 된 데이터 백 기능을 사용하는 경우 여러 서버에 키를 배치하는 방법은 무엇입니까? 요리사 서버 나 클라이언트에 액세스 할 수있는 사람이라면 누구나 레시피에 넣으면 키를 당겨 데이터 백을 해독 할 수 있습니다.

키가 필요한 머신에 있는지 확인하고 스누핑하는 사람으로부터 안전하게 보호하려면 어떻게해야합니까?

답변:


8

불행히도 키가 일반 텍스트로 Chef 노드의 어딘가에 있어야하기 때문에 실제로 할 수있는 일은 많지 않습니다. 누군가가 상자에 대한 쉘 또는 로컬 액세스 권한을 가지고 있다면 키를 읽을 수 있습니다.

약간의 문제를 완화하기 위해베이스 노드에 다음을 추가합니다 (예 : 모든 노드에 공통적 인 레시피 또는 역할).

directory "/etc/chef/keys" do
  mode 0700
  owner "root"
  group "root"
end

키 분배 메커니즘에 상관없이 해당 위치에 키를 넣습니다. 누군가가 키 파일에 올바른 권한을 부여하는 것을 잊어 버린 경우 권한 및 소유권으로 인해 키를 읽을 수 없습니다.

보시다시피 암호화 된 데이터 백은 소스 제어 시스템에서 키 자료를 읽을 수 없도록 보호하고 Chef 노드 자체의 보안 기능은 적습니다.


3

내 EDB는 다음과 같이 구분됩니다.

  • 환경
  • 역할

부트 스트랩 할 때 특별한 접미사가있는 모든 키를 모든 새 EC2 인스턴스에 업로드 한 다음 요리사-클라이언트가 처음 실행될 때 run_list의 레시피에서 사용되지 않은 모든 키를 제거합니다 ( 인스턴스가 시작되는 즉시.)

모든 파일은 소유자 및 그룹 "root"로 업로드되며 읽기 권한 만 있습니다.

EDB를 사용하는 모든 레시피는 'edb_'+ 노드 환경 + 레시피 / 항목 별 이름 + '.key'를 연결하여 레시피 런타임시 EDB 이름 및 키 파일 이름을 생성 한 후이 이름으로 키를 찾습니다. . 존재하지 않는 경우 기본적으로 예외가 발생합니다.

따라서 소파 환경 서버에서 'couch'라는 역할을 실행하여 개발자 환경에서 관리자 사용자에게 사용하는 자격 증명을 얻기 위해 레시피는 'edb_dev_couch.key'라는 키를 찾습니다.

그런 다음 'couch_credentials'라는 항목에 대해 'edb_dev'라는 데이터 백을 검색합니다.

키 관리를 위해 현재 다음과 같은 간단한 접근 방식을 사용하고 있습니다.

  • 부트 스트랩 스크립트를 통해 모든 EDB 키를 업로드하고 키 이름에 '_x'를 추가하십시오.
  • EDB를 사용하는 각 레시피가 키 디렉토리에서 필요한 키를 찾도록하십시오.
  • 키에 '_x'접미사가있는 경우 키 이름을 바꾸어 '_x'접미사를 제거하십시오.
  • 모든 run_list 끝에 '_x'접미사가있는 모든 키를 삭제하는 레시피 추가

바라건대, 이것은 머신이 부트 스트랩되고 chef_client가 처음 실행될 때까지 단일 노드 범위 밖의 키가 영향을받는 시간을 제한합니다.

이것은 키를 보호하는 방법을 테스트하는 첫 번째 테스트이지만, 지금까지는 루트 개발 서버 하나가 EDB에 저장된 다른 서버 자격 증명에 즉시 액세스 할 수 없으므로 현재 요구 사항을 충족합니다.

모든 실행 목록 끝에 하나의 레시피를 유지하기 위해이 exec_keys 레시피가 모든 노드의 마지막 레시피인지 확인하는 나이프 실행 작업을 사용합니다.


0

내 키는 우리가 사용하는 AMI 또는 사용하는 이미지에 구워집니다. 데이터가 안전하지 않기 때문에 부트 스트랩의 일부로하지 않습니다. 조심하지 않으면 일반적으로 로그에 데이터를 볼 수 있습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.