Registering and enrolling identities with a CA

HH·2022년 1월 9일

목록 보기

7/7

CA로 신원 기재하고 등록하기

대상: 조직 관리자, 노드 관리자

신원과 멤버십 서비스 공급자(MSP)에 대한 토픽을 읽었다면 하이퍼레저 페브릭에서는 인증 기관이 인증서를 생성해 관리자, 노드, 유저(클라이언트 어플리케이션)으로 할당하는 것을 알았을 것이다. x.509 인증서를 생성가능한 모든 인증 기관을 신원을 구성하는 공개/개인키 페어를 생성하는데에 사용할 수 있다. 하지만 Fabric CA는 추가적으로 하이퍼레저 페브릭에서 요구하는 로컬 및 조직 MSP 폴더 구조를 생성한다.

이 토픽에서는 신원과 MSP를 생성하기 위해 Fabric CA를 사용하는 "행복한 경로"를 보여줄 것이다. 신원 기재와 등록에 반드시 Fabric CA 를 사용할 필요는 없다. 하지만 다른 CA를 사용한다면 Fabric이 조직, 클라이언트 신원, 그리고 노드들을 빌드하는 데 사용하는 관련 신원들과 MSP들을 만들어야만 한다. 그 MSP 예시들을 아래에서 보여줄 것이다.

기재와 등록 개요

CA 관리자가 신원을 생성하고 공개/개인 키 페어를 대역외로 유저에게 주는 것이 가능하지만, 이 과정은 CA 관리자에게 모든 유저의 개인키에 대한 접근 권한을 준다. 이는 개인키는 어떠한 이유로든 노출되어서는 안된다는 개인키 보안에 대한 기본적인 보안 절차를 위반하는것이다.

따라서 CA 관리자는 유저를 기재(register)한다. 이 프로세스는 CA 관리자가 등록 ID와 비밀번호를 (이는 유저이름과 패스워드와 비슷하다) 신원에게 주고 역할(role) 과 필요한 속성(attributes)을 할당하는 과정이다. CA 관리자는 그 후 이 등록 ID와 비밀번호를 신원의 유저에게 준다. 유저는 Fabric CA client enroll 커맨드를 등록 아이디와 비밀번호를 사용해 실행하고 관리자가 할당한 역할과 속성이 포함된 공개/개인키 페어를 반환받는다.

이 프로세스는 CA의 무결성(오직 CA 관리자만이 유저를 기재하고 역할과 소속(affiliations)을 할당하므로)과 개인키의 무결성(신원의 유저만이 접근할 수 있으므로) 모두를 보존한다.

관리자 신원은 관리자와 노드의 신원 인증서를 생성하는 조직 CA에만 반드시 기재 및 등록될 필요가 있지만, 노드는 반드시 TLS CA에도 기재 및 등록되어야 한다. 이는 서명 및 통신 암호화에 사용되는 공개/개인 TLS 키 페어를 생성한다.

만약 TLS CA가 "TLS" 프로파일만을 사용해 생성되었다면 조직 CA에 신원을 기재/등록하는 커맨드는 TLS CA에 기재/등록하는 커맨드와 동일하다. 두 프로파일을 모두 가진 CA를 사용한 경우 CA와 통신할 때 TLS 프로파일을 지정해주어야 한다. TLS CA로만 기능하는 CA 생성에 대한 더 많은 정보는 CA 배포 가이드를 참고하자.

시작하기 전에

이 튜토리얼에서는 CA서버가 구성되었고 CA 설정 지침을 따라 설정되었다고 가정한다. 신원을 기재할 때(CA 관리자나 registrar 권리를 받은 신원이 처리하는 일이다)와 신원을 등록(enroll)할 때(신원의 유저가 처리하는 일이다) 사용되는 커맨드들과 변수들을 볼 것이다.

각 경우에 fabric-ca-client는 반드시 설정되어야 한다. 이것이 신원이 기재되고 등록될 때 CA 서버를 호출하기 때문이다. 프로적션 환경을 운영하는 경우 TLS를 활성화시켜야 한다. 그리고 TLS 인증서를 CA와의 보안 통신을 위해 준비해야 한다. TLS 인증서는 노드, 관리자, 클라이언트 신원 생성에 사용되는 조직 CA와 나란히 사용하는 TLS CA로부터 와야 하고, 이 TLS CA는 인증서를 생성할 cA와 동일한 CA이다(노드는 서로 통신하기 위해 TLS가 필요하기 때문이다).

폴더 및 인증서 구조 결정

테스트든 프로덕션 환경에서 구동하든, 폴더와 인증서를 관리하기 위해 일관된( consistent and coherent)구조를 유지하는 것이 중요하다. 모든 곳에 동일한 패턴을 사용하는 것이 패브릭의 엄격한 제한사항은 아니다(패스가 정확하기만 하다면 그들을 참조할 때 마다, 예를 들어 노드를 부트스트래핑할 때, 패브릭은 그것을 사용한다). 하지만 인증서 경로 에러는 패브릭 유저가 직면하는 가장 흔한 에러 중 하나다. 사전 계획 및 일관성은 이러한 이슈들을 극적으로 줄인다.

프로덕션 배포는 여기서 보여주지 않는 구조를 포함할 수 있다. 예를 들어 게이트웨이 폴더가 포함될 수 있다. 이것은 관리자가 쉽게 어떤 조직과 노드와 클라이언트들이 각 네트워크에 연관되어 있는지 확인할 수 있게 해 준다. 유사하게 네트워크의 스마트 컨트랙트들이 포함된 스마트 컨트랙트 폴더도 있을 수 있다.

여기서 제시하는 폴더와 인증서 조직화 방법은 필수적이지 않다. 하지만 이것은 CA 배포 가이드나 이 토픽의 나머지 부분과 일치하므로 도움이 될 것이다. 더 중요하게는, 그것들을 소유하고 관리하는 조직을 중심으로 구조를 조직화하게 된다. 피어나 오더링 노드와 같은 물리적 구조 중심으로 배포를 조직화 하는 것이 자연스러워 보일 수 있지만, 실제로 중심 피겨는 조직이다. 특히 모든 네트워크 구성원이 필수적으로 노드를 소유하고 있지 않기 때문에 더욱 그렇다.

여기에 제시되는 구조와 방법은 또한 다음과 같은 상황을 방지하는 모범 사례를 나타내기도 한다. 예를 들어 패브릭이 msp라고 불리는 MSP 폴더를 예상했으나 다른 이름이 사용되었을 경우 폴더의 이름은 관련된 YAML 파일에서 변경되어야 한다.

Fabric CA client 운영을 위한 폴더 구조

(노드를 생성하고 관리자로서 동작하게 하도록 사용하는) CA로부터 다시 받을 인증서를 위한 일관성있는 구조가 중요하지만, 관리자로서 단일 패브릭 CA 클라이언트를 사용해 여러 CA에 커넥트하는 사람들에게도 중요하다. 이는 조직 관리자(필요한 만큼 많은 노드들의 관리자로서 단일 신원만 사용하는)와는 달리 각 CA는 필수적으로 독립된 관리자(부트스트랩될 때 기재되고 추후 등록된)를 가지기 때문이다.

이것이 동일한 CA 클라이언트에서 온 관리자로서 서로 다른 CA 서버에 커넥팅할 때 --mspdir 플래그를 사용하면서 반드시 -u 플래그를 사용해 올바른 CA 서버를 타게팅해야 하는 이유이다. 이는 커넥팅되어 있는 CA의 올바른 CA 관리자 인증서를 지정해준다.

단일 CA 서버를 타겟으로 하는 단일 CA 클라이언트만 사용한다면(조직이나 노드 관리자인 유저에게 더 자주 일어나는 케이스), CA서버를 CA 클라이언트의 구성 파일에서 지정하는 선택지가 있다.

CA 배포 가이드의 프로세스를 따랐다면 아래와 유사한 패브릭 CA 클라이언트 관련 폴더들을 가질 것이다:

파일목록

위 피겨는 여러 CA 서버에 커넥트하기 위해 사용되는 단일 패브릭 CA 클라이언트의 폴더 구조를 보여준다.

보았듯 각 CA 서버는 fabric-ca-client 폴더 아래에 나뉘어진 폴더를 가지고 있다. 각 ca 폴더 안에는 해당 CA 관리자의 공개/개인 키 쌍을 가지고 있는 msp 폴더가 있다. 이것이 CA를 관리할 때 반드시 지정해야 하는 --mspdir이다 (예: 신원 기재).

CA 관리자가 아니지만 Fabric CA 클라이언트를 조직 CA와 TLS CA에 대한 enroll을 수행하기 위해 가지고 있을 경우에도 여전히 단일 패브릭 CA 클라이언트를 사용하는 것이 좋다. 이 CA 클라이언트는 여전히 TLS 인증서를 가지고 있지만(CA 배포 가이드의 프로세스를 사용하며 얻을 수 있다), CA 관리자로써 행위하지 않을 것이므로 CA 관리자 인증서를 가리킬 필요가 없다. 대신 신원을 등록한 관리자에 의해 주어진 등록 ID와 비밀번호가 각 CA 서버와 상호작용하고 필수 인증서를 받도록 해 준다.

조직과 노드 관리자 신원을 위한 폴더 구조

운영하는 CA의 폴더를 패브릭 CA 클라이언트를 사용해 조직화하는 방법은 대부분 일반적인 CA 관리자가 상호작용하는 여러 CA에 의해 결정된다. 하지만 조직 MSP를 조직화하는 조직적인 방법은 얼마나 많은 조직이 생성되고 관리될것인지 예상하는 것에 의해 일부 결정된다.

예를 들어 패브릭 테스트 네트워크에서 피어 조직과 오더러 조직이 생성된다. 결과적으로 네트워크와 관련된 명령어는 ordererOrganization과 peerOrganization 폴더를 가진 organizations 폴더를 생성한다. 이 폴더들 각각은 각 조직을 위한 폴더(조직 MSP와 조직이 소유한 노드 MSP를 포함한)를 가지고 있다.

조직 파일 이미지

위 피겨는 한 관리자에 의해 관리되는 조직의 구조를 보여준다

오더러 조직 생성을 계획하지 않고 있다고 하더라도 이러한 종류의 구조는 배포에 대한 높은 수준의 장기적 유연성을 제공한다. 예를 들어 새 피어를 만들 경우 organizations/<name of org>/<name of new peer> 폴더를 만들 것이라 알 수 있다. 이 <name of new peer> 폴더는 피어가 등록될 때 생성되는 피어 로컬 MSP를 위한 위치가 될 것이다. 또한 TLS CA에 의해 등록될 때 생성되는 인증서를 위한 위치가 될 것이다. 마찬가지로 피어가 속한 조직 MSP의 위치도 조직의 msp 폴더를 참조할 수 있다(여기에는 노드 OUs가 사용중인 경우 configtx.yaml 파일과 조직 관리자(많은 경우 피어 관리자)의 공개 인증서가 포함된다).

조직 구성

_위 피겨는 조직에 의해 소유된 피어의 하위 폴더를 보여준다. peers 폴더 아래에 msp 폴더가 있음을 볼 수 있다. 이것은 피어의 로컬 MSP 폴더로 org1.example.com MSP의 복사본이 아니다.

가장 좋은 방법은 신원 등록 전에 폴더를 미리 만들어두고 등록 커맨드에서 --mspdir 플래그를 사용해 참조하는 것이다. --mspdir 플래그는 기재 단계에서는 CA 관리자의 MSP가 있는 위치를 지정하지만 등록 단계에서는 CA가 반환하는 인증서와 폴더들이 저장될 위치를 가리킨다.

Node OUs

패브릭의 이전 버전에서 신원은 두가지 타입만 가졌다(client, peer). peer 타입은 피어와 오더링 노드에 의해 사용되었다. client 타입은 특정 컨텍스트 내에서 신원을 관리자로 만드는 특별한 admincerts 폴더에 클라이언트 타입을 배치하는 방법과 함께 클라이언트(어플리케이션)과 관리자에 의해 사용되었다.

이제 NodeOUs를 이용해 peer나 client 뿐만이 아니라 orderer나 admin 역할을 CA에 의해 생성되는 인증서에 넣는 것이 가능하고 추천된다. 이것은 신원이 가진 역할을 인증서 안에 임베딩한다.

신원은 역할들 중 하나만을 가질 수 있고, 역할을 활성화시키기 위해서는 관련된 절을 반드시 config.yaml 파일에 복사해 넣어야 한다. 이 파일은 패브릭에 의해 다양한 방법으로 사용된다. 채널 MSP에서는 조직의 관리자가 admin 역할을 가지고 있는지를 검증하는데에 사용된다(이것이 패브릭의 오래된 버전에서 사용되던 admincerts 폴더를 대체한다). 노드의 로컬 MSP에서는 노드 관리자의 admin 역할과 노드 자신의 peer 또는 orderer 역할을 검증한다.

msp 폴더 이름을 원하는대로 바꿀 수 있다. msp는 패브릭 CA 클라이언트에 의해 사용되는 기본 폴더 이름이다. 만약 다른 이름을 골랐다면 그 폴더를 신원 등록 시 --mspdir를 사용해 참조해 주어야 한다. config.yaml를 등록한 신원의 옳은 msp 폴더에 복사하기 위해 아래와 비슷한 커맨드를 사용할 수 있다.

echo 'NodeOUs:
 Enable: true
 ClientOUIdentifier:
   Certificate: cacerts/localhost-7054-ca-org1.pem
   OrganizationalUnitIdentifier: client
 PeerOUIdentifier:
   Certificate: cacerts/localhost-7054-ca-org1.pem
   OrganizationalUnitIdentifier: peer
 AdminOUIdentifier:
   Certificate: cacerts/localhost-7054-ca-org1.pem
   OrganizationalUnitIdentifier: admin
 OrdererOUIdentifier:
   Certificate: cacerts/localhost-7054-ca-org1.pem
   OrganizationalUnitIdentifier: orderer' > path to msp>/msp/config.yaml

또는 Node OU 자료를 msp 폴더의 config.yaml 파일로 수동으로 복사해 넣을 수 있다:

NodeOUs:
  Enable: true
  ClientOUIdentifier:
    Certificate: cacerts/<root CA cert for this org>.pem
    OrganizationalUnitIdentifier: client
  PeerOUIdentifier:
    Certificate: cacerts/<root CA cert for this org>.pem
    OrganizationalUnitIdentifier: peer
  AdminOUIdentifier:
    Certificate: cacerts/<root CA cert for this org>.pem
    OrganizationalUnitIdentifier: admin
  OrdererOUIdentifier:
    Certificate: cacerts/<root CA cert for this org>.pem
    OrganizationalUnitIdentifier: orderer

프로덕션 시나리오에서 유저는 한 조직만을 만들 것으로 가정한다. 하지만 조직을 위해 분리된 파일 구조를 만들고 이 조직 아래에 msp(조직을 정의하는)와 노드들(local MSP와 TLS 섹션을 가진)을 위한 구조를 만드는 것이 좋다.

오더러를 생성할 경우 PeerOUIdentifier를 config.yaml로 복사할 필요는 없다(그 역도 마찬가지다). 하지만 단순화를 위해 전체 섹션을 사용하고 싶을 수도 있다. 추가 절은 악영향을 미치지 않는다. 그리고 동일한 config.yaml 파일을 여러 타입의 노드들과 조직과 관련된 신원들에게 사용할 수 있다.

신원 기재

관리자(또는 유저)에 의해 사용되는 신원과 노드에 의해 사용되는 신원은 다른 목적을 가지고 있지만 근본적으로 단순히 신원들이다: 공개키는 다른 주체들에게 알려지고 비밀 키는 서명에 사용되며, 비밀키가 절대 노출되지 않음에도 생성된 결과물이 비밀키로부터 만들어졌는지를 검증할 수 있는 공개/비밀 키 페어이다.

위에서 논의했듯 신원은 CA 관리자에 의해 CA에 처음 기재된다. 이 신원은 신원의 유저에 의해 등록된다. Fabric CA 클라이언트를 사용한다면, 이 기재 커맨드는 아래와 같이 생겼다 (CA 타입, 등록하려는 신원의 타입과 관계 없이).

./fabric-ca-client register -d --id.name <ID_NAME> --id.secret <ID_SECRET> -u <CA_URL> --mspdir <CA_ADMIN> --id.type <ID_TYPE> --id.attrs $ID_ATTRIBUTE --tls.certfiles <TLSCERT>

변수들은 다음과 같다:

ID_NAME : 신원의 enroll ID. 이 이름은 등록 시 이름을 사용할 유저에게 대역외로 주어진다.
ID_SECRET : 신원의 비밀번호(secret) (password와 유사). 이 비밀번호는 등록 시 사용할 enroll ID와 함께 유저에게 전해진다.
CA_URL : CA의 URL. 기본 포트가 변경되지 않았다면 포트 7054가 뒤따라 온다.
CA_ADMIN : CA 관리자의 인증서 위치 경로.
ID_TYPE : 신원의 타입(또는 역할). 네 가지 가능한 타입이 있다: peer, orderer, admin, client (어플리케이션이 사용한다). 이 타입은 관련된 NodeOU와 반드시 연결되어 있어야 한다. NodeOUs가 사용되지 않는다면 타입과 --id.type 플래그를 무시할 수 있다.
ID_ATTRIBUTE : 해당 신원 특정적인 속성들. 속성에 대한 더 많은 정보는 속성 기반 접근 제어(Attribute based access control)를 확인하자. 이 속성들은 JSON 배열로도 추가될 수 있다. 그러므로 $ID_ATTRIBUTE는 단일 속성을 의미하지 않는다. register 커맨드에서 --id.attrs 다음에 온 어떠한 여러 속성도 될 수 있다.
TLSCERT : TLS CA root 서명 인증서(TLS CA 생성시 만들어진)의 상대 경로.

-d 플래그는 디버그 모드를 활성화시키며, 기재 실패를 디버그하기 유용하다.

관리자 신원 기재 커맨드의 간단한 예:

./fabric-ca-client register -d --id.name org1admin --id.secret org1adminpw -u https://example.com:7054 --mspdir ./org1-ca/msp --id.type admin --tls.certfiles ../tls/tls-ca-cert.pem --csr.hosts 'host1,*.example.com'

신원이 성공적으로 기재된 후 CA 관리자는 등록 ID(org1admin)와 비밀번호(org1adminpw)를 등록할 유저에게 보낸다.

만약 노드를 위한 인증서를 생성하고 있을 경우 조직 CA와 마찬가지로 TLS CA와도 기재 및 등록 작업을 해야 한다.

신원 등록

ㄴ

등록 CA가 설정되고 신원이 기재되면 CA 관리자는 그가 기재 시 사용한 등록 아이디와 비밀번호를 주기 위해 등록할 유저와 대역외로 저촉해야 한다. 그리고 이 아이디와 비밀번호를 사용해서 유저는 그들이 소유한 Fabric CA client 복사본으로 관련된 CA와 접촉해 신원을 등록할 수 있다. 관리자와 노드 신원을 만들기 위해서 사용하는 조직 CA가 대상일 수도 있고 노드가 필요로 하는 TLS 인증서를 생성하는 tLS CA가 대상일 수도 있다. 만약 TLS가 활성화되어 있다면 유저는 반드시 등록에 포함시키기 위해 TLS CA 루트 서명 인증서를 얻어야 한다.

관리자 등록 전에 노드 등록을 진행할 수 있지만 노드 등록 전에 관리자를 먼저 등록하고 조직의 MSP를 만드는 것이 더 합리적이다(피어 노드이든 오더러 노드이든). 노드를 시작하기 전에 관리자 신원을 등록하고 그 인증서를 노드의 로컬 MSP에 두어야 한다.

커맨드는 다음과 같다:

./fabric-ca-client enroll -u https://<ENROLL_ID>:<ENROLL_SECRET><@CA_URL>:<PORT> --mspdir <MSP_FOLDER> --csr.hosts <CSR_HOSTNAME> --tls.certfiles $TLS_CERT

변수들은 다음과 같다:

ENROLL_ID : 신원을 기재할 때 지정된 enroll ID. 이 이름은 유저에게 대역외로 전달되어야 한다.
ENROLL_SECRET : 신원을 기재할 때 지정된 신원의 비밀번호(secret). 이 비밀번호는 유저에게 대역외로 전달되어야 한다.
CA_URL : CA의 URL. 기본 포트가 변경되지 않았다면 포트 7054가 뒤따라 온다. 같은 위치에 두 CA를 구성했다면 --caname 플래그를 사용해 CA를 특정해야 한다. 하지만 이 튜토리얼에서는 CA 배포 튜토리얼 지정된 CA 구성들을 사용한다고 가정한다.
PORT : 등록에 사용하는 CA가 활용하는 포트.
MSP_FOLDER : 파일시스템에서 MSP로의 경로. 노드를 등록중이라면 로컬 MSP이고 관리자를 등록중이라면 조직 MSP이다. --mspdir 플래그로 위치를 지정하지 않는다면 인증서는 현재 위치의 msp 폴더 아래에 위치하게 된다. 해당 폴더가 존재하지 않는다면 생성된다.
CSR_HOSTNAME : 오직 노드 신원과 관련해서, 노드의 도메인 이름을 인코딩한다. 예를 들어 MagnetoCorp는 peer0.mgntoorg.magnetocorp.com라는 호스트명을 선택할 수도 있다.
TLS_CERT : 해당 조직과 관련된 TLS CA root 서명 인증서의 상대 경로.

아래는 앞서 사용한 예시 기재 커맨드와 짝지어지는 등록 커맨드 에시이다:

./fabric-ca-client enroll -u https://org1admin:org1adminpw@example.com:7054 --mspdir ./org1.example.com/msp --csr.hosts 'org1,*.example.com' --tls.certfiles ../tls/tls-ca-cert.pem

등록 커맨드가 공개기/개인키 키 페어만을 반환하는 일반적인 CA와 달리 패브릭 CA는 MSP라고 불리는 폴더 구조를 반환한다. 이 MSP는 노드를 생성할 때나 조직을 채널에 추가할 때 패브릭이 사용할 수 있는 구조를 만드는 데에 사용된다. 관리자 등록의 경우 MSP는 조직의 토대(basis)를 형성한다. 노드 신원 등록의 경우는 노드의 로컬 MSP의 토대를 형성한다. 이 폴더 구조는 TLS CA로부터도 반환된다. 하지만 오직 관련된 TLS 인증서만이 필요하다.

다음은 신원을 등록한 후 반환되는 MSP 샘플이다:
msp 샘플 이미지

위 피겨는 등록에 의해 반환되는 하위 폴더를 보여준다.

인증서 네이밍에서는 당신이 공개 인증서를 참조하고 있는지 개인키를 참조하고 있는지 알기 쉬운 컨벤션을 사용하는 것이 좋다. 둘 모두 .pem 확장자를 가지고 있다는 점을 감안하며, 공개키와 개인키 네이밍을 위해 다음 컨벤선을 고려하자:

공개 인증서를 cert.pem(Fabric CA가 공개 인증서에 주는 기본 이름)에서 의미가 있는 이름으로 변경한다. 예를 들어 Org1 관리자의 공개 인증서는 org1-admin-cert.pem과 같은 이름이 될 수 있다.
개인키를 94u498f9r9fr98t49t345545345_sk에서 org1-admin-key.pem와 같은 의미 있는 이름으로 변경한다.

이 컨벤션에서 .pem 확장자를 붙이기 전 마지막 단어는 무엇인지 구분하기 위해 cert 또는 key가 된다.

등록된 신원으로부터 MSP 만들기

살펴보았듯 Fabric CA로 신원을 등록하면 공개/개인 키 페어뿐만이 아니라 패브릭 네트워크가 사용할 관련된 폴더와 인증서들이 생성된다.

하지만 이 폴더들을 간단히 채널 구성에 (채널에 조직을 가입시키기 위해) 포함시키거나 로컬 MSP를 만들기 위해 노드 로컬 구성에 포함시킬 수 없다. 채널에 추가되어야 하는 조직 MSP 생성의 경우 관리자 개인 키를 삭제해야 한다. 로컬 MSP의 경우 관리자의 공개 인증서를 추가해야 한다.

조직 MSP(채널에 추가되므로 채널 MSP로도 불린다)와 노드의 로컬 MSP에 필요한 폴더나 인증서들에 대해 더 알고 싶다면 MSP 구조를 확인하자.

조직을 채널에 추가하기 위해 필요한 조직 MSP 생성

패브릭 네트워크의 조직은 노드와 마찬가지로 물리적으로 존재하지 않는다. 이들은 채널 구성의 폴더와 인증서 구조로서 존재한다. 이 인증서들은 관련된 루트 CA, 중간 CA(사용되었다면), TLS CA, 그리고 최소 한 관리자 신원으로 식별된다. 멤버십 토픽이나 위 기재, 등록 단계를 다시 떠올려보면 이 폴더들과 인증서들은 관리자 신원 등록 시 Fabric CA client로부터 반환되었다. 이것이 관리자 등록 행위와 조직 생성 행위가 가깝게 연관되어 있는 이유이다.

여기 조직을 채널에 추가할 때 생성해야 하는 폴더 구조 예시가 있다. 이 구조는 채널에 조직을 추가하는 데에 사용하는 방법에 따라 조금씩 다르다. 하지만 어떤 방법이든 이 파일들과 폴더들이 필요하다.

<location of msp>/msp
├── config.yaml
├── cacerts
│   └── cacert.crt
├── intermediatecerts
|   └── cacert.crt
├── tlscacerts
│   └── tlsca.<org-domain>.pem
└── tlsintermediatecerts
    └── tlsca.<org-domain>.pem

이 파일들과 폴더들은 다음과 같다:

cacerts : 관리자의 신원이 기재되고 등록된 조직 CA의 루트 인증서(ca-cert.pem).
intermediatecerts : 사용된 경우 중간 CA의 루트 인증서.
tlscacerts : 이 조직과 관련된 노드들에게 인증서를 발급해주는 TLS CA의 루트 인증서(ca-cert.pem).
tlsintermediatecerts : 만약 사용되었다면 중간 TLS CA의 루트 인증서.

인증서 그 자체는 원하는 대로 이름을 지을 수 있지만 파일 이름을 바꿀 수는 없다. 패브릭이 해당 이름을 가진 폴더를 예상하기 때문이다.

이 조직을 위해 config.yaml 파일을 생성하는 방법은 지침의 NodeOUs를 보자. 패브릭의 오래된 버전에서는 이 파일은 admincerts 폴더에 위치해 있었다. 이 폴더는 조직의 관리자 인증서를 식별하기 위해 필요했다. 더 이상 이 폴더는 필요하지 않다. config.yaml에서 나열된 admin Node OU를 CA로부터 받은 신원은 조직의 관리자가 될 수 있다.

노드의 로컬 MSP 생성

조직의 MSP가 채널 구성에서 조직을 나타내는 반면 노드의 로컬 MSP는 다른 파라미터들과 함께 노드 생성의 일부로 사용되는 논리적 파라미터 모음이다.

위에서 살펴보았듯 노드는 반드시 등록 인증서(노드를 식별하는 공개/개인키 페어)와 노드 간 통신 레이어를 암호화하는 TLS 인증서 둘 모두로 부트스트랩 되어야 한다. 이 부트스트래핑은 노드 생성 시 참조되는 관련 YAML 구성 파일에서 인증서들의 위치를 나열함으로써 일어난다. 이는 노드의 로컬 MSP가 노드가 생성되기 전에 반드시 생성되어야 함을 뜻한다. 노드의 등록 인증서는 그들을 가지고 있는 MSP의 위치를 나열함으로써 지정되는 반면 TLS 인증서는 각 인증서 위치의 절대 경로로 식별된다.

샘플 피어 구성 파일

샘플 오더링 노드 구성 파일

이 구성 파일들은 관련된 로컬 MSP 폴더를 요구한다. 피어는 mspConfigPath를 통해 정의된다. 오더러는 LocalMSPDir로 정의된다. 이 위치에서 찾을 수 있는 폴더들은 노드의 로컬 MSP를 정의하기 위해 사용될 것이다. 여기에는 노드가 서명에 사용할 개인키와 최소한 노드의 한 관리자의 공개키가 포함된다.

반면 TLS 인증서는 폴더를 가리키기보단 독립적으로 정의되고 YAML의 TLS settings 섹션에서 찾을 수 있다. 이는 TLS 인증서가 로컬 MSP와 같은 엄격한 폴더 구조를 유지할 필요가 없음을 뜻한다(특히 외부 CA를 사용해 TLS 인증서를 생성할 사용자의 경우 더욱 그렇다. 이 샘플 YAML 파일을 인증서들이 어디에 사용되는지를 알려주는 가이드로 사용하자). TLS CA로 노드를 등록할 때 생성된 TLS 공개키는 /signcerts 폴더에 저장되고 TLS 개인키는 /keystore 폴더에서 찾을 수 있다. TLS가 활성화된 노드를 만들 때 관련 구성 파일에서 이 파일들을 가리켜야 한다.

노드 YAML 파일의 모든 구성 파라미터들과 같이 msp 폴더와 TLS 인증서 위치를 파일에서 지정하는 방법과 환경 변수를 사용하는 방법이 있다.

네트워크 구동에 컨테이너화된 솔루션을 사용한다면(명백한 이유로 인기 있는 선택이다) 노드가 구동중인 컨테이너 외부에 이 폴더들(볼륨들)을 마운트하는 것이 가장 좋다. 이렇게 하면 노드 컨테이너가 다운되거나 손상되거나 재시작될 경우 인증서가 새 노드를 만들 수 있다.

샘플 로컬 MSP에서 MSP 구조를 확인하자. 단순히 피어 신원을 등록함으로써 이 모든 인증서들을 다시 받을 수는 없다. 예를 들어 부트스트래핑 이전에 users 하위 폴더를 만들고 노드를 관리할 신원의 공개 인증서를 이 폴더에 넣어야 한다. 또한 운영 인증서도 필요하다(네트워크 구성에 따라서 별개의 운영 CA에서 올 수 있다). 운영 서비스에 대한 더 많은 정보는 운영 서비스를 확인하자.

다음은 노드가 등록되고 추가 파일이 추가되었을 때 보일 수 있는 샘플 로컬 MSP 예시이다:

localmsp
  └── config.yaml
  └── cacerts
      └── <root CA public cert>.pem
  └── intermediatecerts
      └── <intermediate CA public cert>.pem
  └── keystore
      └── <node private cert>.pem
  └── signcerts
      └── <node public cert>.pem
  └── tlscacerts
      └── tlsca.<org-domain>.pem
  └── tlsintermediatecerts
      └── tlsca.<org-domain>.pem
  └── operationscerts
      └── operationcert.pem

이 폴더들과 인증서들은 다음과 같다:

cacerts : 관리자의 신원이 기재되고 등록된 조직 CA의 루트 인증서(ca-cert.pem).
intermediatecerts : 사용된 경우 중간 CA의 루트 인증서.
keystore : 노드의 개인키. 노드가 통신에 서명할 때 사용한다.
signcerts : 노드의 공개키. 이 인증서는 들어오는 통신을 하는 노드에게 주어지며, 노드가 올바른 노드와 통신하고 있음을 알기 위해 통신을 초기화 할 수 있도록 한다.
tlscacerts : 이 조직과 관련된 노드과 CA들에게 인증서를 발급해주는 TLS CA의 루트 인증서(ca-cert.pem).
tlsintermediatecerts : 만약 사용되었다면 중간 TLS CA의 루트 인증서.
operationscerts : 운영 서비스와의 상호작용에 필요한 인증서.

인증서 자체는 마음대로 이름지어질 수 있지만 폴더 이름을 바꿔서는 안 된다. 패브릭이 해당 이름을 가진 폴더를 사용한다.

Node OUs가 더 이상 조직 MSP에 관리자 인증서를 필수적으로 포함시키지 않아도 되도록 만든 것과 같이, 노드를 관리하기 위해 노드 관리자의 공개키를 반드시 포함시키지 않아도 된다. config.yaml에서 나열된 admin Node OU를 CA로부터 받은 신원은 조직이 소유한 모든 노드를 관리할 수 있다. 해당 관리자의 공개 인증서를 조직 MSP나 로컬 MSP에 둘 필요는 없다.

이전 포스트