Nebula에는 세 개의 파일이 필요합니다: CA, 호스트 인증서, 호스트 키

누군가에게 Nebula 디렉터리를 건네면 워크스테이션을 절대 떠나서는 안 되는 파일까지 함께 전부 복사합니다. 혼란은 이해할 만합니다. 호스트의 PKI 블록에 있는 세 파일은 서로 비슷하게 생겼고 그중 둘이 인증서이기 때문입니다. 각각은 다른 질문에 답하며 노드에 속하는 것은 둘뿐이므로, 무엇이든 복사하기 전에 역할별로 나누십시오.

세 파일, 세 가지 다른 역할

CA 인증서는 신뢰의 닻이며, 다른 호스트가 자신의 신원을 제시할 때 어느 기관을 믿어야 하는지 호스트에게 알려 줍니다. 호스트 인증서는 노드 자신의 자격 증명이며, 그 기관이 서명합니다. 호스트 키는 그에 대응하는 개인 절반이며 정확히 한 대의 머신에 속합니다. CA 인증서와 자신의 키 쌍을 가진 노드는 오버레이에 참여해 자신이 누구인지 증명할 수 있습니다. 다른 사람의 키를 가진 노드도 그 사람인 척할 수 있으며, 이 구성은 바로 그 실패를 막기 위해 존재합니다.

따라서 동작하는 호스트 디렉터리를 두 번째 머신으로 복사하는 것은 지름길이 아닙니다. 결과가 뻔한 신원 복제입니다.

서명 키는 결코 이동하지 않습니다

CA 서명 키는 어떤 호스트 구성에도 포함되지 않습니다. 새 신원을 만들어 내며, 이를 가진 사람은 어떤 오버레이 주소와 어떤 그룹에 대해서도 인증서를 발급할 수 있습니다. 피어는 서명을 검증하는 데 공개 CA 인증서만 있으면 되므로 개인 절반은 클라이언트에서 아무 역할도 하지 않습니다. 인증서를 발급하는 머신에 보관하고, 실수로 생긴 사본은 편의가 아니라 사고로 취급하십시오.

여러 사람이 인증서를 발급해야 한다면 키 사본이 아니라 절차를 주십시오. 노트북에 있는 공유 서명 키는 아무도 감사하거나 폐기할 수 없는 권한입니다.

호스트 인증서 안에는 무엇이 있는가

호스트 인증서는 파일 이름보다 많은 것을 키에 묶습니다. 노드의 오버레이 주소, 이름, 그룹 소속을 담고 있으며 모두 서명되어 피어가 받아들일지 결정할 수 있습니다. 그래서 호스트 이름을 바꾸는 일은 구성 한 줄을 고치는 것이 아니라 새 인증서를 발급하는 일입니다.

nebula-cert print -path host.crt 실제로 무엇이 발급되었는지 보여 줍니다. 인증서에 의도한 주소가 들어 있다고 가정하기 전에 읽어 보십시오.

다시 읽는 것만으로 충분하지 않을 때가 있습니다

일부 PKI 설정은 신호로 다시 읽히지만, 그렇지 않은 것도 있습니다. 오버레이 주소가 바뀐 인증서 가 다시 읽기가 아니라 프로세스 재시작이 필요한 전형적인 경우입니다.

구성 파일이 말하는 경로만이 아니라 실행 중인 프로세스가 실제로 연 경로를 확인하십시오. 그다음 자격 증명 하나를 바꾸고 연결과 로그를 검증한 뒤에야 다음으로 넘어가십시오. 이전 인증서가 메모리에 남은 채 성공한 것처럼 보이는 다시 읽기는 라우팅 문제처럼 보이는 불일치를 만듭니다. 재시작은 저렴하지만, 오버레이의 절반이 아직 예전 방식으로 보는 신원을 디버깅하는 일은 저렴하지 않습니다.

신원을 제거하려면 차단 목록이 필요합니다

분실하거나 노출된 자격 증명을 교체하는 일에는 두 절반이 있습니다. 새 인증서가 접근을 복구하고, 이전 신원은 더 이상 받아들여지지 않아야 합니다. 이는 별개의 작업이며, 앞의 것만 하면 유출된 자격 증명이 그대로 유효합니다.

차단 목록은 호스트에 배포하는 파일이며, lighthouse가 스스로 밀어내는 것이 아닙니다. 오늘 오프라인인 노드를 포함해 모든 노드에 어떻게 도달할지 계획하고, 어떤 지문을 차단했는지 기록하십시오. 발급 머신에서 키를 교체하고 새 인증서의 세부 정보를 호스트 기록과 함께 보관하십시오. 편집한 머신에만 존재하는 폐기는 폐기가 아닙니다.