Hyperledger Fabric CA는 Hyperledger Fabric용 CA(Certificate Authority)입니다.
이는 다음과 같은 기능을 제공합니다:
- ID 등록 또는 LDAP에 사용자 레지스트리 연결
- 등록 인증서 발급(ECERT)
- 인증서 갱신 및 취소
Hyperledger Fabric CA는 이 문서의 뒷부분에서 설명할 서버와 클라이언트 구성 요소입니다.
Hyperledger Fabric CA에 참여하고 싶은 개발자는 Fabric CA 저장소에서 자세한 내용을 확인하십니오.
개요
아래의 다이어그램은 Hyperledger Fabric CA 서버가 전체 Hyperledger Fabric 아키텍쳐에 적용되는 방식을 보여줍니다.
Hyperledger Fabric CA 서버와 상호 작용하는 방법으론 다음의 두 가지 방식이 있습니다: Hyperledger Fabric CA 클라이언트를 사용하는 방법과 Fabric SDK중 하나를 사용하는 방법입니다.
Hyperledger Fabric CA 서버에 대한 모든 통신은 REST API를 통해서 이루어집니다.
이 REST API에 대한 자세한 내용은 fabric-ca/swagger/swagger-fabric-ca.json을 참조하십시오.
이 설명서는 http://editor2.swagger.io 온라인 에디터를 통해서 볼 수 있습니다.
Hyperledger Fabric CA 클라이언트 또는 SDK는 Hyperledger Fabric CA 서버 클러스터에 연결 할 수 있습니다.
이는 위의 다이어그램 오른쪽 상단에 설명되어 있습니다. 클라이언트는 HA 프록시 End Point로 라우팅하여, Fabric-ca-server 클러스터 구성원 중 하나에 트래픽을 로드 밸런싱 합니다.
클러스터의 모든 Hyperledger Fabric CA 서버는 ID 및 인증서를 추적하기 위해 동일한 데이터베이스를 공유합니다. LDAP이 구성된 경우 ID 정보는 DB가 아닌 LDAP에 보관됩니다.
서버는 여러 CA를 포함할 수 있습니다. 각각의 중간 CA는 루트 CA나 다른 중간 CA를 부모 CA(Parent CA)를 가집니다.
시작하기
선행 사항
- Go언어 1.9버전 이상 설치
- Gopath 환경 변수의 올바른 설정
- libtool 및 libtdhl-dev 패키지 설치
다음의 명령어로 우분투에 libtool 의존성을 설치합니다.
sudo apt install libtool ibltdl-dev
다음의 명령어는 OSX에 libtool 의존성을 설치합니다.
brew install libtool
노트. Homebrew를 통해 libtool을 설치하면 libtldl-dev가 MacOSX에서 필요하지 않습니다.
libtool에 대한 자세한 내용은 https://www.gnu.org/software/libtool을 참조하십시오 .
libltdl-dev에 대한 자세한 내용은 https://www.gnu.org/software/libtool/manual/html_node/Using-libltdl.html을 참조하십시오.
설치
다음으로 $GOPATH/bin에 fabric-ca-server 및 fabric-ca-client 바이너리를 모두 설치합니다.
go get -u github.com/hyperledger/fabric-ca/cmd/...
참고: fabric-ca 저장소를 이미 복제한 경우 위의 'go get' 명령을 실행하기 이전에 master 브랜치에 있는지 확인하십시오. 그렇지 않으면 다음의 오류가 표시 될 수 있습니다.
<gopath>/src/github.com/hyperledger/fabric-ca; git pull --ff-only
There is no tracking information for the current branch.
Please specify which branch you want to merge with.
See git-pull(1) for details.
git pull <remote> <branch>
If you wish to set tracking information for this branch you can do so with:
git branch --set-upstream-to=<remote>/<branch> tlsdoc
package github.com/hyperledger/fabric-ca/cmd/fabric-ca-client: exit status 1
기본 서버 실행
다음의 명령어로 fabric-ca-server를 시작합니다.
fabric-ca-server start -b admin:adminpw
-b 옵션은 부트 스트랩 관리자에 등록 ID와 패스워드를 제공합니다.
LDAP이 "ldap.enabled" 설정으로 활성화되지 않은 경우에 이 작업을 필요로 합니다.
fabric-ca-server-config.yaml이라는 기본 설정 파일은 사용자가 정의 할 수 있는 로컬 디렉토리에 작성됩니다.
Docker를 활용해 서버 시작
Docker 허브
URL: https://hub.docker.com/r/hyperledger/fabric-ca/tags/
보유하고 있는 fabric-ca의 아키텍쳐 및 버전이 일치하는 태그를 찾습니다.
$GOPATH/src/github.com/hyperledger/fabric-ca/docker/server로 이동하여 에디터로 docker-compose.yml을 열도록 합니다.
이전에 찾은 태그를 반영할 수 있도록 image 항목을 변경하십니오. 베타 버전의 x86 아키텍쳐에서는 아래와 같이 보일 수 있습니다.
fabric-ca-server:
image: hyperledger/fabric-ca:x86_64-1.0.0-beta
container_name: fabric-ca-server
ports:
- "7054:7054"
environment:
- FABRIC_CA_HOME=/etc/hyperledger/fabric-ca-server
volumes:
- "./fabric-ca-server:/etc/hyperledger/fabric-ca-server"
command: sh -c 'fabric-ca-server start -b admin:adminpw'
docker-compose.yml 파일과 같은 디렉토리에 있는 터미널을 열어 다음을 실행합니다.
# docker-compose up -d
compose 파일에 지정된 fabric-ca 이미지가 없는 경우 해당 이미지가 삽입되고 fabric-ca 서버 인스턴스가 시작됩니다.
나만의 도커 이미지 만들기
다음의 명령을 입력하면 docker-comsose로 서버를 만들고 시작할 수 있습니다.
cd $GOPATH/src/github.com/hyperledger/fabric-ca
make docker
cd docker/server
docker-compose up -d
The hyperledger/fabric-ca docker 이미지는 fabric-ca-server와 fabric-ca-client 모두 포함하고 있습니다.
# cd $GOPATH/src/github.com/hyperledger/fabric-ca
# FABRIC_CA_DYNAMIC_LINK=true make docker
# cd docker/server
# docker-compose up -d
Fabric CA CLI 살펴보기
이 섹션에서는 편의상 Fabric CA 서버 및 클라이언트를 사용할 수 있는 기본 명령어를 제공합니다.
추가 명령어 정보는 다음 절에서 제공됩니다.
다음 링크는 서버 커맨드 라인과 클라이언트 커맨드 라인을 표시합니다.
문자열 슬라이스(목록)인 커맨드 라인 옵션은 쉼표로 구분된 목록 요소로 옵션을 지정하거나 목록을 구성하는 문자열 값이 있는 옵션을 여러번 지정할 수 있습니다. 예를 들어, host1과 host2를 csr.hosts 옵션에 지정하기 위해선, --csr.hosts 'host1,host2' 또는 --csr.hosts host1, --csr.hosts host2를 입력하여야 합니다. 이전의 형식을 사용할 땐, 쉼표 앞 뒤에 공간이 없는지 확인하십시오.구성 설정
Fabirc CA는 Fabric CA 서버와 클라이언트 설정을 구성하기 위한 3가지 방법을 제시합니다.
해당 방법에 대한 우선 순위는 아래와 같습니다.
- CLI 플래그
- 환경 변수
- 설정 파일
이 문서의 나머지 부분에선 설정 파일을 수정하는 방법에 대해서 설명합니다.
그러나, 설정 파일 변경 사항은 환경 변수나 CLI 플래그를 통해 덮어쓰기가 될 수 있습니다.
예를 들어 클라이언트 설정 파일에 아래와 같은 내용이 있는 경우:
tls:
# Enable TLS (default: false)
enabled: false
# TLS for the client's listenting port (default: false)
certfiles:
client:
certfile: cert.pem
keyfile:
다음의 환경 변수를 cert.pem의 설정 파일 설정을 덮어쓰기 할 수 있습니다.
export FABRIC_CA_CLIENT_TLS_CLIENT_CERTFILE=cert2.pem
만약 환경 변수와 설정 파일 모두 덮어쓰고 싶다면, 아래의 커맨드 라인에서 다음의 플래그를 사용할 수 있습니다.
fabric-ca-client enroll --tls.client.certfile cert3.pem
동일한 방식을 활용하여, FABRIC_CA_CLIENT에서도 해당 변수를 환경 변수에 접두어로 사용되는 것을 제외하고는 FABRIC_CA_SERVER의 사례와 동일합니다.
파일 경로에 대한 단어
파일 이름을 지정하는 Fabric CA 서버 및 클라이언트 설정 파일의 모든 등록 정보는 상대 경로와 절대 경로를 모두 지원합니다. 상대 경로는 설정 파일이 위치한 config 디렉토리와 상대적인 경로입니다.
예를 들자면, ~/config가 config 디렉토리 이고,만약 tls 섹션이 아래와 같다면, Fabric CA server나 client는 ~/config 디렉토리에 있는 root.pem, ~/config/certs 디렉토리의 cert.pem, /abs/path 디렉토리의 key.pem 파일들을 찾을 것 입니다.
tls:
enabled: true
certfiles:
- root.pem
client:
certfile: certs/cert.pem
keyfile: /abs/path/key.pem
Fabric CA 서버
이 섹션에선 Fabric CA 서버에 대해서 설명합니다.
Fabric 서버를 시작하기 이전에 초기화를 이미 하셨을 것 입니다.
이렇게하면 서버를 시작하기 전에 검토하고 사용자 정의 할 수있는 기본 설정 파일을 생성 할 수 있습니다.
- -home 커맨드 라인 옵션이 설정된 경우, 해당 값을 사용합니다.
- 그렇지 않으면
FABRIC_CA_SERVER_HOME환경 변수가 설정되면 해당 값을 사용합니다. - 그렇지 않으면
FABRIC_CA_HOME환경 변수가 설정되면 해당 값을 사용합니다. - 그렇지 않으면
CA_CFG_PATH환경 변수가 설정되면 해당 값을 사용합니다. - 그렇지 않으면 현재 작업 디렉토리를 사용합니다.
이 이후로는, FABRIC_CA_HOME 환경 설정이 $HOME/fabric-ca/server에 설정되어 있다고 가정하고 설명하겠습니다.
아래의 지시 사항부터는 서버 설정 파일이 서버의 홈 디렉토리에 있다고 가정합니다.
서버 초기화
다음 명령어를 활용해서 Fabric CA 서버를 초기화 하십시오.
fabric-ca-server init -b admin:adminpw
LDAP이 disabled 되어 있을 경우엔 -b(부트 스트랩 ID)옵션이 초기화를 위해서 필요합니다.
Fabric CA 서버를 시작하려면 하나 이상의 부트 스트랩 ID가 필요합니다. 위에의 ID는 서버 관리자입니다.
서버 설정 파일에는 구성 할 수있는 CSR (Certificate Signing Request) 섹션이 들어 있습니다. 다음은 CSR 샘플입니다.
cn: fabric-ca-server
names:
- C: US
ST: "North Carolina"
L:
O: Hyperledger
OU: Fabric
hosts:
- host1.example.com
- localhost
ca:
expiry: 131400h
pathlength: 1
위의 모든 필드는 X.509 서명 키 및 fabric-ca-server init으로부터 생성된 인증과 관련이 있습니다.
이는 서버 설정 파일에 있는 ca.certfile과 ca.keyfile에 해당됩니다. 필드는 다음과 같습니다:
- cn 은 일반 이름(Common name)입니다.
- O 는 조직 이름(Organization name)입니다.
- OU 는 조직 단위(Organization Unit)입니다.
- L 은 위치(Location) 또는 도시(city)입니다.
- ST 는 State입니다.
- C 가 나라(Country)입니다.
CSR에 대한 사용자 정의 값이 필요하다면 ca.certfile과 ca.keyfile을 삭제하고 설정 파일을 정의한 뒤 다음의 커맨드를 다시 실행함으로서 해결할 수 있습니다.
fabric-ca-server init -b admin:adminpw
이 커맨드는 -u <parent-fabric-ca-server-URL> 옵션이 지정되지 않는다면 자체 서명된 CA 인증서를 생성합니다.
만약 -u 옵션이 지정된다면, 서버의 CA 인증서가 Fabric 부모(parent) CA 서버에 의해서 서명됩니다.
부모 CA 서버를 인증하기 위해선, URL은 반드시 <scheme>://<enrollmentID>:<secret>@<host>:<port>과 같은 구조여야 하고,
여기서 <enrollmentID> 및 <secret>은 값이 'true'인 'hf.IntermediateCA'속성이있는 ID에 해당합니다.
fabric-ca-server init 명령은 또한 fabric-ca-server-config.yaml이라는 기본 설정 파일을 서버의 홈 디렉토리에 생성합니다.
만약 가지고 있는 CA 서명 인증서 및 Key 파일을 사용해서 Fabric CA 서버를 실행하려는 경우 ca.certfile과 ca.keyfile에 각각의 참조 경로를 배치해야 합니다.
두 파일 모두 PEM으로 인코딩 해야하며, 암호화되어 있어서는 안됩니다.
더욱 구체적으로 설명하자면, CA 인증서 파일의 내용은 -----BEGIN CERTIFICATE-----으로 시작해야하고, Key 파일의 내용은 -----BEGIN PRIVATE KEY-----으로 시작해야 합니다.
-----BEGIN ENCRYPTED PRIVATE KEY-----으로 실행하면 실행에 실패하게 됩니다.
알고리즘 및 키 크기
CSR은 ECDSA(타원 곡선)의 지원을 받는 X.509 인증서와 키를 생성하도록 사용자 정의 할 수 있습니다.
다음의 설정은 곡선 prime256v1과 ecdsa-with-SHA256 서명 알고리즘을 활용하여 ECDSA(Elliptic Curve Digital Signature Algorithm)를 구현하는 예시입니다.
key:
algo: ecdsa
size: 256
알고리즘 및 키 크기의 선택은 보안 요구 사항을 기반으로합니다.
ECDSA(Elliptic Curve Digital Signature Algorithm)는 다음과 같은 주요 크기 옵션을 제공합니다.
| 크기 | ASN1 OID | 서명 알고리즘 |
|---|---|---|
| 256 | prime256v1 | ecdsa-with-SHA256 |
| 384 | secp384r1 | ecdsa-with-SHA384 |
| 521 | secp521r1 | ecdsa-with-SHA512 |
서버 시작
다음과 같이 Fabric CA 서버를 시작합니다.
fabric-ca-server start -b <admin>:<adminpw>
서버가 이전에 초기화되지 않은 경우 처음 시작할 때 서버가 초기화됩니다.
이 초기화 중에 서버는 ca-cert.pem 및 ca-key.pem 파일이 아직 없으면 생성하고 기본 설정 파일도 생성합니다.
참고 항목 초기화에게 Fabric CA 서버섹션을 참조하십시오.
Fabric CA 서버가 LDAP를 사용하도록 구성되어 있지 않으면 다른 ID를 등록하고 등록 할 수 있도록 미리 등록 된 하나 이상의 부트 스트랩 ID로 구성해야합니다.
-b 옵션은 부트 스트랩 ID의 이름과 암호를 지정합니다.
Fabric CA 서버가 http 대신 https에 수신 하도록 하려면, tls.enabled 값을 true로 설정하십시오.
동일한 암호를 사용하여 등록하는 횟수를 제한하려면, 설정 파일의 registry.maxenrollments 값을 적절한 값으로 설정하십시오.
이 값을 1로 설정하면 Fabric CA 서버는 특정 등록 ID에 대해 암호를 한 번만 사용할 수 있습니다.
이 값을 -1로 설정하면 Fabric CA 서버는 등록을 위해 비밀을 재사용 할 수있는 횟수에 제한을 두지 않습니다.
기본값은 -1입니다.
값을 0으로 설정하면 Fabric CA 서버가 모든 ID에 대한 등록을 비활성화하고 ID 등록을 허용하지 않습니다.
이제 Fabric CA 서버가 7054포트에서 수신 대기 State일 것 입니다.
Fabric CA 서버가 클러스터에서 실행되도록 구성하거나 LDAP를 사용하지 않으려면 Fabric CA 클라이언트 섹션으로 건너 뛸 수 있습니다 .
Database 구성
이 절에서는 PostgreSQL 또는 MySQL 데이터베이스에 연결하도록 Fabric CA 서버를 구성하는 방법에 대해 설명합니다.
기본 데이터베이스는 SQLite이고 기본 데이터베이스 파일은 Fabric CA 서버 홈 디렉토리의 fabric-ca-server.db에 있습니다.
클러스터에서 Fabric CA 서버 실행에 신경 쓰지 않으면이 절을 건너 뛸 수 있습니다.
그렇지 않으면 아래의 버전 사양으로 PostgreSQL 또는 MySQL을 구성해야합니다.
Fabric CA는 클러스터 설정에서 다음 데이터베이스 버전을 지원합니다.
- PostgreSQL : 9.5.5 이상
- MySQL : 5.7 이상
PostgreSQL
다음 샘플은 PostgreSQL 데이터베이스에 연결하기 위해 서버의 설정 파일에 추가 될 수 있습니다. 다양한 값을 적절하게 사용자 정의해야합니다.
데이터베이스 이름에는 어떤 문자가 허용되는지에 대한 제한 사항이 있습니다.
자세한 내용은 다음 Postgres 문서를 참조하십시오.
https://www.postgresql.org/docs/current/static/sql-syntax-lexical.html#SQL-SYNTAX-IDENTIFIERS
db:
type: postgres
datasource: host=localhost port=5432 user=Username password=Password dbname=fabric_ca sslmode=verify-full
sslmode를 지정 하면 SSL 인증 유형이 구성됩니다. sslmode의 유효한 값은 다음과 같습니다.
| 모드 | 설명 |
|---|---|
| disable | SSL 없음 |
| require | 항상 SSL (확인 건너 뛰기) |
| verify-ca | 항상 SSL (서버가 제공 한 인증서가 신뢰할 수있는 CA에 의해 서명되었는지 확인) |
| verify-full | verify-ca와 동일하며 서버가 제공 한 인증서가 신뢰할 수있는 CA에 의해 서명되었고 서버 호스트 이름이 인증서의 인증서와 일치하는지 확인합니다. |
TLS를 사용하려면, Fabric CA 서버의 db.tls 섹션이 지정되어야만 합니다.
PostgreSQL 서버에서 SSL 클라이언트 인증을 사용하는 경우 db.tls.client 섹션에 클라이언트 인증서와 키 파일도 지정해야합니다.
다음은 db.tls 섹션 의 예입니다.
db:
...
tls:
enabled: true
certfiles:
- db-server-cert.pem
client:
certfile: db-client-cert.pem
keyfile: db-client-key.pem
certfiles - PEM으로 인코딩 된 신뢰할 수있는 루트 인증서 파일 목록
certfile 및 keyfile - PostgreSQL 서버와 안전하게 통신하기 위해 Fabric CA 서버에서 사용하는 PEM 인코딩 인증서 및 키 파일
PostgreSQL SSL 설정
PostgreSQL 서버에서 SSL을 구성하기위한 기본 지침 :
- postgresql.conf에서 SSL의 주석 처리를 제거하고 "on"(SSL = on)으로 설정하십시오.
- 인증서와 키 파일을 PostgreSQL 데이터 디렉토리에 저장하십시오.
다음에 대한 자체 서명 인증서 생성 지침 :https://www.postgresql.org/docs/9.5/static/ssl-tcp.html
참고 : 자체 서명 인증서는 테스트 용이므로 프로덕션 환경에서 사용하면 안됩니다.
PostgreSQL 서버 - 클라이언트 인증서 필요
- 신뢰할 수있는 인증 기관 (CA)의 인증서를 PostgreSQL 데이터 디렉토리의 root.crt 파일에 배치합니다.
- postgresql.conf에서 클라이언트의 루트 인증서 (CA cert)를 가리 키도록 "ssl_ca_file"을 설정합니다.
- pg_hba.conf의 해당 hostssl 행에서 clientcert 매개 변수를 1로 설정하십시오.
PostgreSQL 서버에서 SSL을 구성하는 방법에 대한 자세한 내용은 다음 PostgreSQL 설명서를 참조하십시오.https://www.postgresql.org/docs/9.4/static/libpq-ssl.html
MySQL
다음 샘플은 Fabric CA 서버 설정 파일에 추가되어 MySQL 데이터베이스에 연결될 수 있습니다. 다양한 값을 적절하게 사용자 정의해야합니다. 데이터베이스 이름에는 어떤 문자가 허용되는지에 대한 제한 사항이 있습니다. 자세한 내용은 다음 MySQL 설명서를 참조하십시오. https://dev.mysql.com/doc/refman/5.7/en/identifiers.html
MySQL 5.7.X에서 특정 모드는 서버가 '0000-00-00'을 유효한 날짜로 허용하는지 여부에 영향을 미칩니다. MySQL 서버가 사용하는 모드를 완화해야 할 수도 있습니다. 우리는 서버가 0의 날짜 값을 받아 들일 수있게하려고합니다.
my.cnf에서 sql_mode 구성 옵션을 찾아 NO_ZERO_DATE를 제거하십시오 . 이 변경 후 MySQL 서버를 다시 시작하십시오.
사용 가능한 다른 모드에 대한 다음 MySQL 설명서를 참조하고 사용중인 특정 버전의 MySQL에 대한 적절한 설정을 선택하십시오.
https://dev.mysql.com/doc/refman/5.7/en/sql-mode.html
db:
type: mysql
datasource: root:rootpw@tcp(localhost:3306)/fabric_ca?parseTime=true&tls=custom
TLS를 통해 MySQL 서버에 연결하는 경우, db.tls.client 섹션은 위의 PostgreSQL 섹션에서 설명한 것과 같은 것이 필요합니다.
MySQL SSL 설정
MySQL 서버에서 SSL을 구성하기위한 기본 지침 :
- 서버용 my.cnf 파일을 열거 나 작성하십시오. [mysqld] 섹션에서 아래 줄을 추가하거나 주석을 제거하십시오. 이것들은 서버의 키와 인증서 및 루트 CA 인증서를 가리켜 야합니다. 서버 및 클라이언트 측 인증서 생성에 대한 지침 :http://dev.mysql.com/doc/refman/5.7/en/creating-ssl-files-using-openssl.html [mysqld] ssl-ca = ca-cert.pem ssl-cert = server-cert.pem ssl-key = server-key.pem 다음 쿼리를 실행하여 SSL이 활성화되었는지 확인할 수 있습니다. mysql> SHOW GLOBAL VARIABLES LIKE ‘have_%ssl’; 쿼리 실행 결과: {| class="wikitable" !변수 이름 !값 |- |have_openssl |예 |- |have_ssl |예 |}
- 서버 측 SSL 설정이 완료되면 다음 단계는 SSL을 통해 MySQL 서버에 액세스 할 수있는 권한을 가진 사용자를 생성하는 것입니다. 이를 위해 MySQL 서버에 로그인하고 다음을 입력하십시오.
mysql> GRANT ALL PRIVILEGES ON . TO ‘ssluser’@’%’ IDENTIFIED BY ‘password’ REQUIRE SSL; mysql> FLUSH PRIVILEGES;
- 사용자가 서버에 액세스 할 특정 IP 주소를 지정하려면 '%'를 특정 IP 주소로 변경하십시오.
MySQL 서버 - 클라이언트 인증서 필요
보안 연결 옵션은 서버 측에서 사용되는 옵션과 유사합니다.
ssl-ca는 CA (Certificate Authority) 인증서를 식별합니다. 이 옵션을 사용하면 서버에서 사용하는 것과 동일한 인증서를 지정해야합니다.
ssl-cert는 MySQL 서버 인증서를 식별합니다.
ssl-key는 MySQL 서버의 개인 키를 식별합니다.
특별한 암호화 요구 사항이 없거나 REQUIRE SSL 옵션이 포함 된 GRANT 문을 사용하여 생성 된 계정을 사용하여 연결하려고한다고 가정합니다.
보안 연결 옵션의 권장 세트로서 최소한 -ssl-cert 및 -ssl-key 옵션을 사용하여 MySQL 서버를 시작하십시오.
그런 다음 서버 설정 파일에 db.tls.certfiles 정보를 설정하고, Fabric CA 서버를 시작합니다.
클라이언트 인증서도 지정되도록 요구하려면 REQUIRE X509 옵션을 사용하여 계정을 만드십시오.
그런 다음 클라이언트는 적절한 클라이언트 키와 인증서 파일을 지정해야합니다.
그렇지 않으면 MySQL 서버가 연결을 거부합니다.
Fabric CA 서버에 대한 클라이언트 키 및 인증서 파일을 지정하려면 db.tls.client.certfile과 db.tls.client.keyfile 구성 등록 정보를 설정합니다.
LDAP 설정
Fabric CA 서버는 LDAP 서버에서 읽을 수 있도록 구성 할 수 있습니다.
특히 Fabric CA 서버는 LDAP 서버에 연결하여 다음 작업을 수행 할 수 있습니다.
등록하기 전에 ID를 인증한다.
권한 부여에 사용되는 ID의 속성 값을 검색합니다.
Fabric CA 서버 구성 파일의 LDAP 섹션을 수정하여 서버가 LDAP 서버에 연결되도록 구성하십시오.
ldap:
# Enables or disables the LDAP client (default: false)
enabled: false
# The URL of the LDAP server
url: <scheme>://<adminDN>:<adminPassword>@<host>:<port>/<base>
userfilter: <filter>
attribute:
# 'names' is an array of strings that identify the specific attributes
# which are requested from the LDAP server.
names: <LDAPAttrs>
# The 'converters' section is used to convert LDAP attribute values
# to fabric CA attribute values.
#
# For example, the following converts an LDAP 'uid' attribute
# whose value begins with 'revoker' to a fabric CA attribute
# named "hf.Revoker" with a value of "true" (because the expression
# evaluates to true).
# converters:
# - name: hf.Revoker
# value: attr("uid") =~ "revoker*"
#
# As another example, assume a user has an LDAP attribute named
# 'member' which has multiple values of "dn1", "dn2", and "dn3".
# Further assume the following configuration.
# converters:
# - name: myAttr
# value: map(attr("member"),"groups")
# maps:
# groups:
# - name: dn1
# value: orderer
# - name: dn2
# value: peer
# The value of the user's 'myAttr' attribute is then computed to be
# "orderer,peer,dn3". This is because the value of 'attr("member")' is
# "dn1,dn2,dn3", and the call to 'map' with a 2nd argument of
# "group" replaces "dn1" with "orderer" and "dn2" with "peer".
converters:
- name: <fcaAttrName>
value: <fcaExpr>
maps:
<mapName>:
- name: <from>
value: <to>
용어 설명:
- scheme: ldap 또는 ldaps 중 하나입니다 .
- adminDN: 관리자 사용자의 고유 이름입니다.
- pass: 관리자 사용자의 암호입니다.
- host: LDAP 서버의 호스트 이름 또는 IP 주소입니다.
- port: 옵션 포트 번호는입니다에 대한 기본 389 LDAP 및 636 LDAPS ;
- base: 검색에 사용할 LDAP 트리의 선택적 루트입니다.
- filter: 로그인 사용자 이름을 고유 이름으로 변환하기 위해 검색 할 때 사용하는 필터입니다. 예를 들어 값이 로그인 사용자 이름 인 속성 (uid=%s)값이있는 LDAP 항목 을 검색 하는 값입니다 uid. 마찬가지로 (email=%s)이메일 주소로 로그인하는 데 사용할 수 있습니다.
- LDAPAttrs: 사용자를 대신하여 LDAP 서버에 요청할 LDAP 속성 이름의 배열입니다.
- attribute.converters 섹션은 LDAP 속성을 fabric CA 속성으로 변환하는 데 사용됩니다. 여기서 * fcaAttrName는 fabric CA 속성의 이름입니다. * fcaExpr는 계산 된 값이 fabric CA 속성에 지정된 표현식입니다. 예를 들어 <LDAPAttrs>가 [ "uid"]이고 <fcaAttrName>이 'hf.Revoker'이고 <fcaExpr>이 'attr ( "uid") = ~ "revoker *"'라고 가정합니다. 즉, "uid"라는 이름의 속성이 사용자를 대신하여 LDAP 서버에 요청됩니다. 사용자의 'uid'LDAP 속성 값이 'revoker'로 시작하면 'hf.Revoker'속성에 'true'값이 부여됩니다. 그렇지 않은 경우 사용자는 'hf.Revoker'속성에 대해 'false'값이 제공됩니다.
- attribute.maps 섹션은 LDAP 응답 값을 매핑하는 데 사용됩니다. 일반적인 사용 사례는 LDAP 그룹과 관련된 고유 이름을 ID 유형으로 매핑하는 것입니다.
LDAP 표현식 언어는 https://github.com/Knetic/govaluate/blob/master/MANUAL.md에 설명 된 govaluate 패키지를 사용합니다.
이것은 "= ~"와 같은 연산자와 정규 표현식 인 "revoker *"와 같은 리터럴을 정의합니다.
기본 govaluate 언어를 확장하는 LDAP 관련 변수 및 함수는 다음과 같습니다.
- DN: 사용자의 고유 이름과 동일한 변수입니다.
- affiliation: 사용자의 소속와 동등한 변수입니다.
- attr1: 또는 2 개의 인수를 취하는 함수입니다. 첫 번째 인수는 LDAP 속성 이름입니다. 두 번째 인수는 여러 값을 단일 문자열로 조인하는 데 사용되는 구분 기호 문자열입니다. 기본 구분 기호 문자열은 ","입니다. 이 attr함수는 항상 'string'유형의 값을 반환합니다.
- map2: 개의 인수를 취하는 함수입니다. 첫 번째 인수는 임의의 문자열입니다. 두 번째 인수는 첫 번째 인수의 문자열에 대해 문자열 대체를 수행하는 데 사용되는지도의 이름입니다.
- if: 첫 번째 인수가 부울 값으로 해석되어야하는 3 개의 인수를 취하는 함수입니다. true로 평가되면 두 번째 인수가 반환됩니다. 그렇지 않으면 세 번째 인수가 반환됩니다.
예를 들자면, 다음 표현식은 사용자가 "O=Org1,C=US"라는 구별가능한 이름을 가지고 있거나 "admin"속성이 "true"인 경우에 true로 평가됩니다.
DN = ~ "* O = org1, C = US"|| (affiliation = ~ "org1.dept2. *"&& attr ( 'admin') = 'true')참고 :이 attr함수는 항상 'string' 값을 반환하므로 숫자 연산자는 식을 생성하는 데 사용할 수 없습니다. 예를 들어, 다음은 유효한 표현식이 아닙니다.
value: attr("gidNumber) >= 10000 && attr("gidNumber) < 10006또는 다음과 같이 따옴표로 묶인 정규 표현식을 사용하여 동일한 결과를 반환 할 수 있습니다.
value: attr("gidNumber") =~ "1000[0-5]$" || attr("mail") == "root@example.com"다음은 OpenLDAP서버의 기본 설정에 대한 샘플 설정 섹션이고, OpenLDAP 서버에 다음의 docker 이미지를 가지고 있습니다.
https://github.com/osixia/docker-openldap
ldap:
enabled: true
url: ldap://cn=admin,dc=example,dc=org:admin@localhost:10389/dc=example,dc=org
userfilter: (uid=%s)OpenLDAP 도커 이미지를 시작, 구성, FABRIC_CA / cli / server / ldap / ldap_test.go에서 LDAP 테스트 실행, OpenLDAP 서버 중지를 하는 스크립트에 대해서는 FABRIC_CA / scripts / run-ldap-tests를 참조하십시오.
LDAP가 구성되면 등록은 다음과 같이 작동합니다.
- Fabric CA 클라이언트 또는 클라이언트 SDK는 기본 인증 헤더와 함께 등록 요청을 보냅니다.
- Fabric CA 서버는 등록 요청을 수신하고 인증 헤더에서 ID 이름과 암호를 해독하고 구성 파일에서 "userfilter"를 사용하여 ID 이름과 관련된 DN (Distinquished Name)을 조회 한 다음 해당 ID의 패스워드와 LDAP 바인딩을 시도합니다. LDAP 바인딩이 성공하면 등록 처리가 승인되고 계속 진행할 수 있습니다.
클러스터 설정
IP 스프레이어를 사용하여 Fabric CA 서버 클러스터에 로드 밸런싱을 조정할 수 있습니다. 이 섹션에서는 Fabric CA 서버 클러스터로 라우팅하도록 Haproxy를 설정하는 방법에 대한 예제를 제공합니다. Fabric CA 서버의 설정을 반영하도록 호스트 이름과 포트를 변경하십시오.
haproxy.conf
global
maxconn 4096
daemon
defaults
mode http
maxconn 2000
timeout connect 5000
timeout client 50000
timeout server 50000
listen http-in
bind *:7054
balance roundrobin
server server1 hostname1:port
server server2 hostname2:port
server server3 hostname3:port
참고: TLS를 사용하는 경우에는 mode tcp를 사용해야 합니다.
다중 CA 설정
fabric-ca 서버는 기본적으로 단일 기본 CA로 구성됩니다. 그러나 cafiles 또는 cacount 구성 옵션 을 사용하여 추가 CA를 단일 서버에 추가 할 수 있습니다. 각 추가 CA에는 자체 홈 디렉토리를 가지게 됩니다.
cacount:
cacount는 x개의 기본 추가 CA를 시작하는 빠른 방법을 제공합니다.
홈 디렉토리는 서버 디렉토리에 상대적입니다. 이 옵션을 사용하면 디렉토리 구조가 다음과 같이됩니다.
--<Server Home>
|--ca
|--ca1
|--ca2각각의 추가 CA는 홈 디렉토리에 생성 된 기본 설정 파일을 가져옵니다. 구성 파일에는 고유 한 CA 이름이 포함됩니다.
예를 들어, 다음 명령은 2 개의 기본 CA 인스턴스를 시작합니다.
fabric-ca-server start -b admin:adminpw --cacount 2
cafiles:
cafiles 구성 옵션을 사용할 때 절대 경로가 제공되지 않으면 CA 홈 디렉토리는 서버 디렉토리에 상대적입니다.
이 옵션을 사용하려면 시작될 각 CA에 대해 CA 구성 파일이 이미 생성되고 구성되어 있어야합니다.
각 구성 파일에는 고유 한 CA 이름과 CN (Common Name)이 있어야합니다.
그렇지 않을 경우엔 이름이 고유해야하므로 서버가 시작되지 않습니다.
CA 구성 파일은 기본 CA 구성을 무시하며 CA 구성 파일의 누락 된 옵션은 기본 CA의 값으로 대체됩니다.
선행 순서는 다음과 같습니다.
- CA 구성 파일
- 기본 CA CLI 플래그
- 기본 CA 환경 변수
- 기본 CA 구성 파일
CA 구성 파일에는 최소한 다음 내용이 포함되어야합니다.
ca:
# Name of this CA
name: <CANAME>
csr:
cn: <COMMONNAME>
다음과 같이 디렉토리 구조를 구성 할 수 있습니다.
--<Server Home>
|--ca
|--ca1
|-- fabric-ca-config.yaml
|--ca2
|-- fabric-ca-config.yaml
예를 들어, 다음 명령은 사용자 정의 된 두 CA 인스턴스를 시작합니다.
fabric-ca-server start -b admin:adminpw --cafiles ca/ca1/fabric-ca-config.yaml
--cafiles ca/ca2/fabric-ca-config.yaml
중간 CA 등록
중간 CA에 대한 CA 서명 인증서를 만들려면 중간 CA는 Fabric ca 클라이언트가 CA에 등록하는 것과 같은 방법으로 상위 CA에 등록해야합니다.
이 작업은 -u 옵션을 사용하여 아래 표시된 것처럼 부모 CA의 URL과 등록 ID 및 암호를 지정하여 수행됩니다.
이 등록 ID와 연관된 ID에는 이름이 "hf.IntermediateCA"이고 값이 "true"인 속성이 있어야합니다. 발급된 인증서의 CN (또는 Common Name)은 등록 ID로 설정됩니다.
중간 CA가 명시적으로 CN 값을 지정하려고하면 오류가 발생합니다.
fabric-ca-server start -b admin:adminpw -u http://<enrollmentID>:<secret>@<parentserver>:<parentport>
다른 중간 CA 플래그의 경우 Fabric CA 서버의 구성 파일 형식 섹션을 참조하십시오.
서버 업그레이드
Fabric CA 클라이언트를 업그레이드하기 전에 Fabric CA 서버를 업그레이드해야합니다. 업그레이드하기 전에 현재 데이터베이스를 백업하는 것이 좋습니다.
- sqlite3을 사용하는 경우 현재 데이터베이스 파일 (기본적으로 fabric-ca-server.db라는 이름)을 백업하십시오.
- 다른 데이터베이스 유형의 경우 적절한 백업 / 복제 메커니즘을 사용하십시오.
Fabric CA 서버의 단일 인스턴스를 업그레이드하려면 다음을 수행하십시오.
- fabric-ca-server 프로세스를 중지하십시오.
- 현재 데이터베이스가 백업되었는지 확인하십시오.
- 이전 fabric-ca-server 바이너리를 업그레이드 된 버전으로 교체하십시오.
- fabric-ca-server 프로세스를 시작하십시오.
- 다음 명령으로 fabric-ca-server 프로세스를 사용할 수 있는지 확인하십시오. 여기서 <host>는 서버가 시작된 호스트 이름입니다.
fabric - ca - 클라이언트 getcacert - u http : // < host > : 7054
클러스터 업그레이드
MySQL 또는 Postgres 데이터베이스를 사용하여 fabric-ca-server 인스턴스의 클러스터를 업그레이드하려면 다음 절차를 수행하십시오.
host1 및 host2의 두 fabric-ca-server 클러스터 구성원 (각각 포트 7054에서 수신 대기)에로드 밸런싱을 위해 haproxy를 사용한다고 가정합니다.
이 절차를 수행하면 업그레이드 된 fabric-ca-server 클러스터 구성원으로로드 밸런싱이 수행되고, 각각 host3 및 host4에서 포트 7054에서 수신 대기합니다.
haproxy 통계를 사용하여 변경 사항을 모니터링하려면 통계 수집을 활성화하십시오.
haproxy 구성 파일의 전역 섹션에 다음 행을 추가합니다.
stats socket /var/run/haproxy.sock mode 666 level operator
stats timeout 2m
변경 사항을 적용하려면 haproxy를 다시 시작하십시오.
# haproxy -f <configfile> -st $ (pgrep haproxy)
haproxy "show stat"명령의 요약 정보를 표시하려면 다음 함수가 반환되는 많은 양의 CSV 데이터를 구문 분석하는 데 유용 할 수 있습니다.
haProxyShowStats () {
echo "show stat"| nc -U /var/run/haproxy.sock | sed '1s / ^ # * //'|
awk -F ','-v fmt = "% 4s % 12s % 10s % 6s % 6s % 4s % 4s \ n" '
(i = 1; i = NF; i ++) f [tolower ($ i)] = i}에 대해 if (NR == 1)
$ f [ "svname"], $ f [ "status"], $ f [ "svname"],
$ f [ "weight"], $ f [ "act"], $ f [ "bck"]} '
}
1. 처음에 haproxy 구성 파일은 다음과 유사합니다.
server server1 host1:7054 check
server server2 host2:7054 check
이 구성을 다음과 같이 변경하십시오.
2. 다음과 같이 새 구성으로 Haproxy를 다시 시작하십시오.
haproxy -f <configfile> -st $(pgrep haproxy)
이제 "haproxyShowStats"가 2개의 활성 이전 백업 서버와 2개의 업그레이드가 된 서버(아직 시작되지 않은)가 있는 수정된 설정을 반영하게 될 것입니다.
sid pxname svname status weig act bck
1 fabric-cas server3 DOWN 1 1 0
2 fabric-cas server4 DOWN 1 1 0
3 fabric-cas server1 UP 1 0 1
4 fabric-cas server2 UP 1 0 1
3. host3 및 host4에 fabric-ca-server의 업그레이드 된 바이너리를 설치하십시오.
host3 및 host4의 새로운 업그레이드 된 서버는 host1 및 host2의 이전 버전과 동일한 데이터베이스를 사용하도록 구성되어야합니다.
업그레이드 된 서버를 시작하면 데이터베이스가 자동으로 마이그레이션됩니다.
haproxy는 백업 서버로 구성되지 않았기 때문에 모든 새 트래픽을 업그레이드 된 서버로 전달합니다.
"fabric-ca-client getcacert" 명령어를 사용해서 클러스터가 계속 제대로 작동 하는지 확인하는지 확인하십시오.
또한, "haProxyShowStats"는 이제 다음과 같이 모든 서버가 활성 State임을 반영하게됩니다.
sid pxname svname status weig act bck 1 fabric-cas server3 UP 1 1 0 2 fabric-cas server4 UP 1 1 0 3 fabric-cas server1 UP 1 0 1 4 fabric-cas server2 UP 1 0 1
4. host1과 host2에서 이전 서버를 중지하십시오. 이후 단계로 진행하기 이전에 새 클러스터가 계속 제대로 작동 하는지 확인하는 명령을 사용해여 확인하십시오.
그런 다음 haproxy 구성 파일에서 이전 서버 백업 구성을 제거하여 다음과 유사하게 만듭니다.
server server3 host3:7054 check
server server4 host4:7054 check
5. 다음과 같이 새 구성 설정으로 HA 프록시를 다시 시작하십시오.
haproxy -f <configfile> -st $(pgrep haproxy)
"haProxyShowStats"는 이제 새 버전으로 업그레이드 된 두 개의 활성 서버가 있는 수정된 구성 설정이 반영됩니다.
sid pxname svname status weig act bck 1 fabric-cas server3 UP 1 1 0 2 fabric-cas server4 UP 1 1 0
Fabric CA 클라이언트
이 섹션에서는 fabric-ca-client 명령어를 사용하는 방법에 대해서 설명합니다.
Fabric CA 클라이언트의 홈 디렉토리는 다음과 같이 결정됩니다:
- -home 커맨드 라인 옵션이 설정된 경우, 해당 값을 사용합니다.
- 그렇지 않으면 FABRIC_CA_CLIENT_HOME환경 변수가 설정되면 해당 값을 사용합니다.
- 그렇지 않으면 FABRIC_CA_HOME 환경 변수가 설정되면 해당 값을 사용합니다.
- 그렇지 않으면 CA_CFG_PATH 환경 변수가 설정되면 해당 값을 사용합니다.
- 그렇지 않으면 $HOME/.fabric-ca-client를 사용합니다.
이후의 지침부터는 클라이언트 구성 파일이 클라이언트의 홈 디렉토리에 있다고 가정합니다.
부트 스트랩 ID 등록
필요한 경우에, 우선 클라이언트 구성 파일에서 CSR(Certificate Signing Request) 섹션을 사용자 정의하십시오.
csr.cn 필드는 부트 스트랩 ID로 설정되어야만 한다는 것을 참고하시길 바랍니다.
디폴트 CSR 값은 다음과 같습니다.
csr:
cn: <<enrollment ID>>
key:
algo: ecdsa
size: 256
names:
- C: US
ST: North Carolina
L:
O: Hyperledger Fabric
OU: Fabric CA
hosts:
- <<hostname of the fabric-ca-client>>
ca:
pathlen:
pathlenzero:
expiry:
필드에 대한 설명은 CSR Field를 확인하십시오.
다음으로, fabric-ca-client enroll 명령어를 실행하여 ID를 등록하십시오.
예를 들어 아래의 명령은 7054 포트에서 실행되는 Fabric CA 서버를 호출하여 ID는 admin이고, 비밀번호가 adminpw인 계정을 등록합니다.
export FABRIC_CA_CLIENT_HOME=$HOME/fabric-ca/clients/admin
fabric-ca-client enroll -u http://admin:adminpw@localhost:7054
enroll 명령어는 Enrollment Certificate(ECert), 그에 해당하는 개인 키, CA 인증서 체인 PEM 파일을 Fabric CA 클라이언트 msp 디렉토리의 하위 디렉토리에 저장합니다.
이후 PEM 파일의 저장 위치를 확인할 수 있는 메시지가 표시됩니다.
새 ID 등록
등록 요청을 수행하는 ID는 현재 등록되어 있어야하며 등록중인 ID의 유형을 등록 할 수있는 적절한 권한이 있어야합니다.
특히 다음과 같이 등록하는 동안 Fabric CA 서버에서 세 가지 권한 부여 검사가 수행됩니다.
- 등록자 (즉, 호출자)는 쉼표로 구분 된 값 목록이있는 "hf.Registrar.Roles"속성이 있어야합니다. 이 값 중 하나는 등록 할 ID 유형과 동일합니다. 예를 들어, 등록자가 "peer, app, user"값을 갖는 "hf.Registrar.Roles"속성을 갖는 경우, 등록자는 피어, 앱 및 사용자 유형의 ID를 등록 할 수 있지만 순서 지정자는 등록 할 수 없습니다.
- 등록 기관의 소속은 등록 된 가맹(affiliation) ID와의 접두사와 같아야합니다. 예를 들어, "a.b"의 가맹 ID가있는 등록 기관은 "a.b.c"의 가맹 ID를 등록 할 수 있지만 "a.c"의 가맹 ID를 등록 할 수 없습니다. ID에 루트 소속이 필요한 경우 가맹 요청은 점( ".") 이어야하며 등록 기관도 루트 가맹을 가져야합니다. 등록 요청에 가맹이 지정되지 않은 경우 등록중인 ID에 등록 기관의 소속이 부여됩니다.
- 등록자는 다음 조건이 모두 충족 될 경우 유저 및 유저 속성을 등록 할 수 있습니다.
- 등록자는 접두사 'hf'가있는 Fabric CA 예약 속성을 등록 할 수 있습니다. 등록자가 속성을 소유하고 'hf.Registrar.Attributes' 속성 값의 일부인 경우에만 해당됩니다. 또한, 속성이 list 유형 인 경우, 등록되는 속성의 값은 등록자가 가지고있는 값의 부분 집합과 같아야합니다. 속성이 부울 값 인 경우 등록자는 속성에 대한 등록자 값이 '참'인 경우에만 속성을 등록 할 수 있습니다.
- 사용자 정의 속성 (즉, 이름이 'hf.'로 시작하지 않는 속성)을 등록하려면 등록자에 속성 또는 패턴 값이 등록 된 'hf.Registar.Attributes'속성이 있어야합니다. 유일하게 지원되는 패턴은 끝에 "*"가있는 문자열입니다. 예를 들어, "a.b *"는 "a.b"로 시작하는 모든 속성 이름과 일치하는 패턴입니다. 예를 들어, 등록자가 hf.Registrar.Attributes = orgAdmin을 갖는 경우, 등록자가 ID에 추가하거나 제거 할 수있는 유일한 속성은 'orgAdmin'속성입니다.
- 요청 된 속성 이름이 'hf.Registrar.Attributes'인 경우,이 속성에 대해 요청 된 값이 'hf.Registrar.Attributes'에 대한 등록자 값의 부분 집합과 같은지 추가 확인이 수행됩니다. 이 값이 참이 되려면 요청 된 각 값이 등록 기관의 'hf.Registrar.Attributes'속성 값과 일치해야합니다. 예를 들어 등록자의 'hf.Registrar.Attributes'값이 'a.b.*,x.y.z'이고 요청 된 속성 값이 'a.b.c,x.y.z'인 경우 'a.b.c'가 'a.b.*'와 일치하고 'x.y.z'가 등록자의 'x.y.z' 값 일치하므로 유효합니다.
- 예
유효한 시나리오 :
- 등록자에 'hf.Registrar.Attributes = a.b.*,x.y.z'속성이 있고 'a.b.c'속성을 등록하는 경우 유효한 'a.b.c'는 'a.b.*'와 일치합니다.
- 등록자에 'hf.Registrar.Attributes = a.b.*,x.y.z'속성이 있고 속성 'x.y.z'를 등록하는 경우 'x.y.z'가 등록자의 'x.y.z'값과 일치하므로 유효합니다.
- 등록자가 'hf.Registrar.Attributes = a.b.*,x.y.z'속성을 갖고 요청 된 속성 값이 'a.b.c,x.y.z'이면 'a.b.c'가 'a.b.*'와 일치하고 'x.y.z'가 등록자의 'x.y.z'값입니다.
- 등록자에 'hf.Registrar.Roles = peer,client' 속성가 있고 요청 된 속성 값이 'peer'또는 'peer, client'인 경우 요청 된 값이 등록자 값의 서브 세트와 같거나 유효하기 때문에 유효합니다 .
잘못된 시나리오 :
- 등록자에 'hf.Registrar.Attributes = a.b.*,x.y.z'속성이 있고 'hf.Registar.Attributes = a.b.c,x.y.*'속성을 등록하는 경우 요청 된 속성 'x.y.*'이 소유 된 패턴이 아니기 때문에 유효하지 않습니다. 'x.y.*' 값은 'x.y.z'의 상위 집합입니다.
- 등록자에 'hf.Registrar.Attributes = a.b.*,x.y.z'속성이 있고 'hf.Registar.Attributes = a.b.c,x.y.z,attr1'속성을 등록하는 경우 등록자의 'hf.Registrar.Attributes'속성이 유효하지 않으므로 유효하지 않습니다 값은 'attr1'을 포함하지 않습니다.
- 등록자에 'hf.Registrar.Attributes = a.b.*,x.y.z'속성이 있고 'a.b'속성을 등록하는 경우 값 'a.b'가 'ab *'에 포함되어 있지 않으므로 유효하지 않습니다.
- 등록자에 'hf.Registrar.Attributes = a.b.*,x.y.z'속성이 있고 속성 'x.y'를 등록하는 경우 'x.y'가 'x.y.z'에 포함되지 않아 유효하지 않습니다.
- 등록자에 'hf.Registrar.Roles = peer, client'속성이 있고 요청 된 속성 값이 'peer, client, orderer'인 경우 등록자에 hf.Registrar.Roles 속성 값의 순서 역할이 없으므로 유효하지 않습니다.
- 등록자에 'hf.Revoker = false'속성이 있고 요청 된 속성 값이 'true'인 경우 hf.Revoker 속성이 부울 속성이고 등록자 값이 'true'가 아니므로 유효하지 않습니다.
아래 표에는 ID에 등록 할 수있는 모든 속성이 나열되어 있습니다.
속성 이름은 대소 문자를 구분합니다.
| Name | Type | Description |
|---|---|---|
| hf.Registrar.Roles | List | 등록 기관이 관리 할 수있는 역할 목록 |
| hf.Registrar.DelegateRoles | List | 등록자가 'hf.Registrar.Roles'속성에 대해 등록 트리에 부여할 수 있는 역할 목록 |
| hf.Registrar.Attributes | List | 등록자가 등록할 수 있는 속성 목록 |
| hf.GenCRL | Boolean | Identity는 속성 값이 true 인 경우 Identity에서 CRL을 생성 가능 |
| hf.Revoker | Boolean | Identity는 속성 값이 true 인 경우 사용자 및 / 또는 인증서를 철회 가능 |
| hf.AffiliationMgr | Boolean | Identity는 속성 값이 true 인 경우 가맹 관리 가능 |
| hf.IntermediateCA | Boolean | Identity는 속성 값이 true 인 경우 중간 CA로서 등록 가능 |
다음의 명령문은 등록 ID가 admin2, org1.department1로 가맹되었고, 이름이 hf.Revoker인 속성의 값이 true인 새로운 사용자를 등록하기 위해서 admin ID의 자격 증명을 사용합니다.
": ecert"접미사는 기본적으로 "admin"속성과 그 값이 사용자 등록 인증서에 삽입되어 접근 제어 결정을 내릴 수 있음을 의미합니다.
export FABRIC_CA_CLIENT_HOME=$HOME/fabric-ca/clients/admin
fabric-ca-client register --id.name admin2 --id.affiliation org1.department1 --id.attrs 'hf.Revoker=true,admin=true:ecert'
등록 암호라고도하는 암호가 인쇄됩니다. 이 암호는 ID를 등록하는 데 필요합니다. 이를 통해 관리자는 ID를 등록할 수 있고 ID를 등록하기 위한 등록 ID와 암호로서 다른 사람에게 제공 할 수 있습니다.
-id.attrs 플래그의 일부로 여러 속성을 지정할 수 있으며 각 속성은 쉼표로 구분되어야합니다. 쉼표가 들어있는 속성 값의 경우 속성을 큰 따옴표로 묶어야합니다. 아래 예를 참조하십시오.
fabric-ca-client register -d --id.name admin2 --id.affiliation org1.department1 --id.attrs '"hf.Registrar.Roles=peer,user",hf.Revoker=true'
또는
fabric-ca-client register -d --id.name admin2 --id.affiliation org1.department1 --id.attrs '"hf.Registrar.Roles=peer,user"' --id.attrs hf.Revoker=true
클라이언트의 구성 파일을 편집하여 register 명령에 사용 된 모든 필드의 기본값을 설정할 수 있습니다. 예를 들어 구성 파일에 다음과 같이 포함되어 있다고 가정합니다.
id:
name:
type: user
affiliation: org1.department1
maxenrollments: -1
attributes:
- name: hf.Revoker
value: true
- name: anotherAttrName
value: anotherAttrValue
다음 명령은 명령 줄에서 가져 오는 등록 ID가 "admin3"인 새 ID를 등록하고, 나머지는 Identity type: "user", affiliation: "org1.department1”,
두 개의 속성인 “hf.Revoker” and “anotherAttrName”와 같은 정보를 포함하고 있는 구성 파일에서 가져옵니다.
export FABRIC_CA_CLIENT_HOME=$HOME/fabric-ca/clients/admin
fabric-ca-client register --id.name admin3
여러 속성으로 ID를 등록하려면 위와 같이 구성 파일에 모든 속성 이름과 값을 지정해야합니다.
maxenrollment를 0으로 설정 하거나 구성에서 제외하면 ID가 CA의 최대 등록 값을 사용하도록 등록됩니다.
또한 등록되는 ID의 최대 등록 값은 CA의 최대 등록 값을 초과 할 수 없습니다.
예를 들어 CA의 최대 등록 값이 5 인 경우 새 ID는 5보다 작거나 같은 값을 가져야하며 -1로 설정하면 안됩니다 (무한 등록의 문제 발생).
다음 섹션에서 피어를 등록하는 데 사용할 피어 ID를 등록 해 봅시다.
다음 명령은 peer1 ID를 등록합니다 .
우리는 서버가 우리를 위해 암호를 생성하는 대신에 우리 자신의 암호 (또는 비밀번호)를 지정하기로 결정했습니다.
export FABRIC_CA_CLIENT_HOME=$HOME/fabric-ca/clients/admin
fabric-ca-client register --id.name peer1 --id.type peer --id.affiliation org1.department1 --id.secret peer1pw
소속은 항상 소문자로 저장되는 서버 구성 파일에 지정된 리프가 아닌 소속을 제외하고 대소 문자를 구분합니다.
예를 들어 서버 구성 파일의 소속 섹션이 다음과 같은 경우:
affiliations:
BU1:
Department1:
- Team1
BU2:
- Department2
- Department3BU1, Department1, BU2는 소문자로 저장됩니다. 이는 Fabric CA가 Viper를 사용하여 구성을 읽었기 때문입니다.
Viper는 맵 키의 대소 문자를 구분하지 않고 항상 소문자 값을 반환합니다.
Team1 가맹 ID를 등록하려면, bu1.department1.Team1은 -id.affiliation에 지정되어야합니다.
이에 대한 사항은 아래에서 찾아보실 수 있습니다.
export FABRIC_CA_CLIENT_HOME=$HOME/fabric-ca/clients/admin
fabric-ca-client register --id.name client1 --id.type client --id.affiliation bu1.department1.Team1
피어 ID 등록
피어 ID를 성공적으로 등록 했으므로 이제 등록 ID와 암호 (예 : 이전 섹션 의 암호) 를 사용하여 피어를 등록 할 수 있습니다 . 이것은 "-M"옵션을 사용하여 Hyperledger Fabric MSP (Membership Service Provider) 디렉토리 구조를 채우는 방법을 시연하는 것을 제외하고는 부트 스트랩 ID를 등록하는 것과 비슷합니다.
다음 명령은 peer1을 등록합니다. "-M"옵션의 값을 피어의 core.yaml 파일에있는 'mspConfigPath'설정 인 피어의 MSP 디렉토리 경로로 바꾸십시오. FABRIC_CA_CLIENT_HOME을 동료의 홈 디렉토리로 설정할 수도 있습니다.
export FABRIC_CA_CLIENT_HOME = $ HOME / fabric-ca / clients / peer1
fabric-ca-client enroll -u http : // peer1 : peer1pw @ localhost : 7054 -M $ FABRIC_CA_CLIENT_HOME / msp
Orderer 등록은 MSP 디렉토리 경로가 Orderer의 orderer.yaml 파일에있는 'LocalMSPDir'설정을 제외하고는 동일합니다.
fabric-ca-server에서 발급 한 모든 등록 인증서에는 다음과 같이 조직 단위 (또는 "OU")가 있습니다.
- OU 계층 구조의 루트는 ID 유형과 동일합니다.
- ID 정보의 각 구성 요소에 대해 OU가 추가됩니다.
예를 들어, ID 유형이 Peer고 조직이 depertment1.team1인 경우 ID의 OU 계층 구조 (리프에서 루트까지)는 OU = team1, OU = department1, OU = peer 입니다.
다른 Fabric CA 서버에서 CA 인증서 체인 가져 오기
일반적으로 MSP 디렉토리의 cacerts 디렉토리에는 피어에 대한 모든 신뢰 루트를 나타내는 다른 인증 기관의 인증 기관 체인이 있어야합니다.
fabric-ca-client getcacerts 명령은 다른 Fabric CA 서버 인스턴스에서 이러한 인증서 체인을 검색하는 데 사용됩니다.
예를 들어, 다음은 "CA2"라는 이름으로 포트 7055에서 청취하는 localhost에서 두 번째 Fabric CA 서버를 시작합니다.
이는 완전히 다른 신뢰의 루트를 나타내며 블록 체인의 다른 구성원에 의해 관리됩니다.
export FABRIC_CA_SERVER_HOME=$HOME/ca2
fabric-ca-server start -b admin:ca2pw -p 7055 -n CA2
다음 명령을 통해 CA2의 인증서 체인을 peer1의 MSP 디렉토리에 설치합니다.
export FABRIC_CA_CLIENT_HOME=$HOME/fabric-ca/clients/peer1
fabric-ca-client getcacert -u http://localhost:7055 -M $FABRIC_CA_CLIENT_HOME/msp
기본적으로 Fabric CA 서버는 하위 순서로 CA 체인을 반환합니다. 즉, 체인의 각 CA 인증서 뒤에 발급자의 CA 인증서가옵니다.
Fabric CA 서버가 반대 순서로 CA 체인을 반환해야하는 경우 환경 변수 CA_CHAIN_PARENT_FIRST를 true로 설정 하고 Fabric CA 서버를 다시 시작하십시오.
Fabric CA 클라이언트는 두 가지 Order를 적절히 처리합니다.
ID(Identity) 재등록
등록 인증서가 만료 되려고하거나 손상되었다고 가정하십시오.
재등록 명령을 실행하여 다음과 같이 등록 인증서를 갱신 할 수 있습니다.
export FABRIC_CA_CLIENT_HOME=$HOME/fabric-ca/clients/peer1
fabric-ca-client reenroll
인증서 또는 ID 폐기
ID 또는 인증서를 폐기 할 수 있습니다. ID를 취소하면 ID이 소유 한 모든 인증서가 폐기되고 ID이 새 인증서를 얻지 못하게됩니다. 인증서를 해지하면 단일 인증서가 무효화됩니다.
인증서 또는 ID를 해지하려면 호출 ID에 hf.Revoker 및 hf.Registrar.Roles 속성 이 있어야 합니다. 폐지 ID는 ID의 소속과 동등하거나 ID의 가맹 정보를 가진 접두사가 있는 인증서 또는 ID만을 취소 할 수 있습니다. 또한, 폐지 요청자는 요청자의 hf.Registrar.Roles 속성에 나열된 유형의 ID만 취소 할 수 있습니다 .
예를 들어, orgs.org1과 'hf.Registrar.Roles = peer,client'속성을 가진 폐기 요청자는 orgs.org1 또는 orgs.org1.department1 과 소속된 피어 또는 클라이언트 유형 ID를 취소 할 수 있지만 orgs.org2 또는 기타 유형의 가맹된 ID를 취소 할 수는 없습니다..
다음 명령은 ID를 사용 불가능하게하고 ID와 연관된 모든 인증서를 취소합니다. Fabric CA 서버가이 ID로 수신 한 모든 향후 요청이 거부됩니다.
fabric-ca-client revoke -e <enrollment_id> -r <reason>
아래의 요소들은 -r 플래그를 사용해서 지정할 수 있는 지원 가능한 사유입니다.
- unspecified
- keycompromise
- cacompromise
- affiliationchange
- superseded
- cessationofoperation
- certificatehold
- removefromcrl
- privilegewithdrawn
- aacompromise
예를 들자면, 소속 트리의 루트와 연결된 브트 스트랩 관리자는 다음과 같이 Peer1의 ID를 폐기할 수 있습니다.
export FABRIC_CA_CLIENT_HOME=$HOME/fabric-ca/clients/admin
fabric-ca-client revoke -e peer1
ID에 속하는 등록 인증서는 다음과 같이 AKI (Authority Key Identifier) 및 일련 번호를 지정하여 해지 할 수 있습니다.
fabric-ca-client revoke -a xxx -s yyy -r <reason>
예를 들어 openssl 명령어를 사용해서 AKI와 인증의 시리얼 키를 얻을 수 있고 그 정보를 revoke 명령어를 통해서 해당 인증서를 폐지할 수 있습니다.
이에 대한 명령어는 다음과 같습니다.
serial=$(openssl x509 -in userecert.pem -serial -noout | cut -d "=" -f 2)
aki=$(openssl x509 -in userecert.pem -text | awk '/keyid/ {gsub(/ *keyid:|:/,"",$1);print tolower($0)}')
fabric-ca-client revoke -s $serial -a $aki -r affiliationchange
-getcrl 플래그는 해지된 모든 인증서를 포함하고 있는 CRL(Certified Revocation List)를 생성 할 수 있습니다.
예를 들어 다음의 명령은 peer1 ID를 폐기, CRL을 생성, <msp폴더>/crls/crl.pem 파일에 저장합니다.
fabric-ca-client revoke -e peer1 --gencrl
CRL은 gencrl명령을 사용하여 생성 할 수도 있습니다 .
CRL(Certified Revocation List) 생성하기 섹션을 통해서 gencrl 명령어에 대한 자세한 내용을 확인할 수 있습니다.
CRL (인증서 해지 목록) 생성
Fabric CA 서버에서 인증서가 폐기 된 후에는 Hyperledger Fabric의 해당 MSP도 업데이트해야합니다. 여기에는 해당 채널 구성 블록에 피어의 로컬 MSP와 MSP가 모두 포함됩니다. 이렇게하려면 PEM으로 인코딩 된 CRL (인증서 해지 목록) 파일을 MSP 의 폴더에 저장해야합니다 . fabric-ca-client 명령을 사용하여 CRL을 생성 할 수 있습니다. gencrlhf.GenCRL 특성을 가진 모든 ID 는 특정 기간 동안 해지 된 모든 인증서의 일련 번호를 포함한 CRL을 만들 수 있습니다. 생성된 CRL은 <msp folder>/crls/crl.pem 파일에 저장됩니다.
다음 명령은 폐기 된 모든 인증서(만료되었거나 및 만료되지 않은)를 포함하는 CRL을 만들고 ~/msp/crls/crl.pem 파일에 CRL을 저장 합니다.
export FABRIC_CA_CLIENT_HOME=~/clientconfig
fabric-ca-client gencrl -M ~/msp
다음 명령은 2017-09-13T16:39:57-08:00(-revokeafter 플래그로 지정) 이후와 2017-09-21T16:39:57-08:00(-revokebefore 플래그로 지정 ) 이전에 해지 된 모든 인증서 (만료되고 만료되지 않은)를 포함하는 CRL을 만듭니다. 그리고 그 결과를 ~/msp/crls/crl.pem파일에 CRL을 저장합니다.
export FABRIC_CA_CLIENT_HOME=~/clientconfig
fabric-ca-client gencrl --caname "" --revokedafter 2017-09-13T16:39:57-08:00 --revokedbefore 2017-09-21T16:39:57-08:00 -M ~/msp
-caname 플래그는 요청을 받은 CA의 이름을 지정합니다. 이 예시에선 gencrl 요청을 기본 CA에 전송하였습니다.
-revokedafter와 -revokedbefore 플래그는 시간 차동안 상하 바운더리를 지정합니다.
생성된 CRL은 이 시간 차 동안 폐지된 인증서만을 포함합니다. 값은 RFC3339 포멧으로 지정된 UTC 형식의 타임스템프를 가집니다.
-revokeafter 타임스탬프는 -revokebefore 타임스탬프보다 큰 값이어서는 안됩니다.
기본적으로, CRL의 다음 업데이트 날짜는 해당 일자의 다음 날로 지정됩니다. crl.expiry의 CA 구성 등록 정보는 사용자 정의 값을 지정할 수 있습니다.
gencrl 명령어는 또한 -expireafter와 -expirebefore 플래그도 받아들입니다. 해당 플래그들은 폐기된 인증서 중 기간동안 만료된 인증서 정보를 CRL에 생성합니다.
예를 들어 아래의 명령어는 2017-09-13T16:39:57-08:00부터 2017-09-21T16:39:57-08:00까지의 폐기 인증서 정보와 중 2017-09-13T16:39:57-08:00부터 2018-09-13T16:39:57-08:00까지의
기간동안 만료된 인증서 정보를 포함한 CRL을 생성합니다.
export FABRIC_CA_CLIENT_HOME=~/clientconfig
fabric-ca-client gencrl --caname "" --expireafter 2017-09-13T16:39:57-08:00 --expirebefore 2018-09-13T16:39:57-08:00 --revokedafter 2017-09-13T16:39:57-08:00 --revokedbefore 2017-09-21T16:39:57-08:00 -M ~/msp
Fabric-samples/fabric-ca 샘플은 폐지 사용자의 인증서를 포함하고 있는 CRL을 생성하고 채널의 MSP를 업데이트 하는 방법을 보여줍니다.
그런 다음에 폐지된 사용자 자격 증명을 이용해서 채널에 쿼리를 보내면 인증 오류 발생을 출력합니다.
TLS 활성화
이 섹션에서는 Fabric CA 클라이언트에 TLS를 구성하는 방법에 대해 자세히 설명합니다.
다음 섹션은 fabric-ca-client-config.yaml 구성합니다.
tls:
# Enable TLS (default: false)
enabled: true
certfiles:
- root.pem
client:
certfile: tls_client-cert.pem
keyfile: tls_client-key.pem
certfile 옵션은 클라이언트가 신뢰할 수 있는 루트 인증서의 집합입니다.
이는 일반적으로 ca-cert.pem 파일에 해당하는 서버의 홈 디렉토리에 있는 루트 Fabric CA 서버 인증서 입니다.
client 옵션은 상호 TLS가 서버에서 구성되었을 경우에 필요합니다.
속성 기반 접근 제어
접근 제어 결정은 ID의 속성에 따라 체인 코드 (및 Hyperledger Fabric 런타임에 의해)로 이루어질 수 있습니다. 이를 Attribute-Based Access Control 또는 ABAC 라고 부릅니다 .
이를 가능하게하기 위해 ID의 등록 인증서(ECert)는 하나 이상의 속성 이름과 값을 포함 할 수 있습니다. 그런 다음 체인 코드는 속성 값을 추출하여 접근 제어 결정을 내립니다.
예를 들어 응용 프로그램 app1을 개발 중이며 app1 관리자 만 특정 체인 코드 작업에 접근 할 수 있도록하려고 한다고 가정합니다 . 체인 코드는 호출자의 인증서 (채널에 대해 신뢰할 수있는 CA에서 발급 받은)에 true 값을 갖는 app1Admin 이라는 속성이 있는지 확인할 수 있습니다 . 물론 속성의 이름은 무엇이든 될 수 있으며 값은 부울 값일 필요가 없습니다.
따라서 속성이있는 등록 인증서를 어떻게 얻기 위한 두 가지 방법이 있습니다.
- ID를 등록 할 때 ID에 대해 발행 된 등록 인증서에 기본적으로 속성이 포함되도록 지정 할 수 있습니다. 이 동작은 등록 시 무시 될 수 있지만 기본 동작를 설정하는 데 유용하며 응용 프로그램 외부에서 등록이 수행된다고 가정하면 응용 프로그램을 변경할 필요가 없습니다. 다음은 app1Admin 과 email의 두 속성으로 user1 을 등록하는 방법을 보여줍니다 . ": ecert"접미사 는 사용자가 등록시 명시 적으로 속성을 요청하지 않은 경우 기본적으로 appAdmin 속성이 user1의 등록 인증서에 삽입되도록합니다. 이메일 속성은 기본적으로 등록 인증서에 추가되지 않습니다.
fabric-ca-client register --id.name user1 --id.secret user1pw --id.type user --id.affiliation org1 --id.attrs 'app1Admin=true:ecert,email=user1@gmail.com'
- ID를 등록 할 때 하나 이상의 속성을 인증서에 추가하도록 명시적으로 요청할 수 있습니다. 요청된 각 속성에 대해 속성이 선택적인지 여부를 지정할 수 있습니다. 선택적으로 요청하지 않았고 ID에 특성이없는 경우 오류가 발생합니다.
다음은 app1Admin 속성 없이 email 속성을 사용하여 user1 을 등록하는 방법 과 사용자가 phone 속성을 소유하고있는 경우 선택적으로 phone 속성 을 등록하는 방법을 보여줍니다 .
fabric-ca-client enroll -u http://user1:user1pw@localhost:7054 --enrollment.attrs "email,phone:opt"
아래의 표는 매 ID 등록이 자동적으로 발생하는 세 가지 속성을 보여줍니다.
| 속성 이름 | 속성 값 | ||
|---|---|---|---|
| hf.EnrollmentID | 신원의 등록 ID | ||
| hf.Type | 신원 유형 | ||
| hf.Affiliation | 신원의 소속 |
위의 속성을 디폴트 값으로 인증서에 추가하기 위해선, 명시적으로 "ecert" 사양에 맞추어 속성을 등록해야만 합니다.
예를 들어, 다음은 등록시 특정 속성이 요청되지 않으면 'hf.Affiliation'속성이 등록 인증서에 추가되도록 ID 'user1'을 등록합니다.
소속의 값('org1')은 '-id.affiliation'및 '-id.attrs'플래그에서 동일해야 한다는 점을 주의하세요.
fabric-ca-client register --id.name user1 --id.secret user1pw --id.type user --id.affiliation org1 --id.attrs 'hf.Affiliation=org1:ecert'
속성 기반 액세스 제어를위한 체인 코드 라이브러리 API에 대한 자세한 내용은 https://github.com/hyperledger/fabric/tree/release-1.1/core/chaincode/lib/cid/README.md를 참조 하십시오.
애트리뷰트 기반 액세스 제어 등을 보여주는 엔드 투 엔드 샘플은 https://github.com/hyperledger/fabric-samples/tree/release-1.1/fabric-ca/README.md를 참조 하십시오.
동적 서버 구성 업데이트
이 절에서는 fabric-ca-client를 사용하여 서버를 다시 시작하지 않고 fabric-ca-server 구성의 일부를 동적으로 업데이트하는 방법에 대해 설명합니다.
이 절의 모든 명령은 fabric-ca-client enroll 명령을 사용해서 등록이 되어 있는 State여야 합니다.
ID 동적 업데이트 하기
이 절에서는 fabric-ca-client를 사용하여 ID를 동적으로 업데이트하는 방법에 대해 설명합니다.
클라이언트 ID가 다음을 모두 만족시키지 않으면 인증 실패가 발생합니다.
- 클라이언트 ID는 쉼표로 구분 된 값 목록이있는 "hf.Registrar.Roles"속성을 가져야하며 값 중 하나는 업데이트되는 ID 유형과 동일해야합니다. 예를 들어 클라이언트 ID에 "client, peer"값이있는 "hf.Registrar.Roles"속성이 있으면 클라이언트는 'client'및 'peer'유형의 ID를 업데이트 할 수 있지만 'orderer'는 업데이트 할 수 없습니다.
- 클라이언트 ID의 소속은 업데이트되는 ID의 소속와 같거나 접두사 여야합니다. 예를 들어, "ab"의 소속을 가진 클라이언트는 "abc"의 소속으로 신원을 업데이트 할 수 있지만 "ac"의 소속으로 신원을 업데이트 할 수 없습니다. ID에 루트 소속이 필요한 경우 업데이트 요청에 소속에 대한 점 ( ".")을 지정해야하며 클라이언트에는 루트 소속이 있어야합니다.
다음은 소속을 추가, 수정 및 제거하는 방법을 보여줍니다.
신원 정보 얻기
호출자가 호출자가 위 섹션에서 강조 표시된 권한 요구 사항을 충족하는 경우 호출자는 fabric-ca 서버에서 ID에 대한 정보를 검색 할 수 있습니다. 다음 명령은 ID를 얻는 방법을 보여줍니다.
fabric-ca-client identity list --id user1
호출자는 다음 명령을 실행하여 볼 수있는 권한이있는 모든 ID에 대한 정보를 검색하도록 요청할 수도 있습니다.
fabric-ca-client identity list
신원 추가
다음은 'user1'에 대한 새로운 ID를 추가합니다. 새 ID를 추가하면 'fabric-ca-client register'명령을 통해 ID를 등록하는 것과 동일한 작업을 수행합니다. 새 ID를 추가하는 방법에는 두 가지가 있습니다. 첫 번째 방법은 JSON 문자열에서 ID를 설명하는 플래그를 사용하는 것입니다.
fabric-ca-client identity add user1 --json '{"secret": "user1pw", "type": "user", "affiliation": "org1", "max_enrollments": 1, "attrs": [{"name": "hf.Revoker", "value": "true"}]}'다음은 루트 소속을 가진 사용자를 추가합니다. 소속 이름 "."은 루트 소속을 의미합니다.
fabric-ca-client identity add user1 --json '{"secret": "user1pw", "type": "user", "affiliation": ".", "max_enrollments": 1, "attrs": [{"name": "hf.Revoker", "value": "true"}]}'ID를 추가하는 두 번째 방법은 직접 플래그를 사용하는 것입니다. 'user1'을 추가하는 방법은 아래 예제를 참조하십시오.
fabric-ca-client identity add user1 --secret user1pw --type user --affiliation . --maxenrollments 1 --attrs hf.Revoker=true
아래 표에는 ID의 모든 필드와 ID가 필수인지 또는 선택적인지 여부 및 기본값이있을 수있는 모든 기본값이 나열되어 있습니다.
| Fields | Required | Default Value |
|---|---|---|
| ID | Yes | |
| Secret | No | |
| Affiliation | No | Caller’s Affiliation |
| Type | No | client |
| Maxenrollments | No | 0 |
| Attributes | No |
신원 수정
기존 ID를 수정할 수있는 두 가지 방법이 있습니다. 첫 번째 방법은 플래그 를 통해 JSON 문자열의 ID에 대한 수정 사항을 설명하는 것입니다. 단일 요청으로 여러 수정 작업을 수행 할 수 있습니다. 수정되지 않은 ID의 모든 요소는 원래 값을 유지합니다.
참고 : maxenrollments 값 "-2"는 CA의 최대 등록 설정을 사용하도록 지정합니다.
아래 명령은 -json 플래그를 사용하여 ID에 대한 다중 수정을 수행합니다.
fabric-ca-client identity modify user1 --json '{"secret": "newPassword", "affiliation": ".", "attrs": [{"name": "hf.Regisrar.Roles", "value": "peer,client"},{"name": "hf.Revoker", "value": "true"}]}'아래 명령은 직접 플래그를 사용하여 수정합니다. 다음은 ID 'user1'에 대한 등록 암호 (또는 암호)를 'newsecret'으로 갱신합니다.
fabric-ca-client identity modify user1 --secret newsecret
다음은 identity 'user1'이 'org2'에 속하는 것을 갱신합니다.
fabric-ca-client identity modify user1 --affiliation org2
다음은 ID 'user1'의 유형을 'peer'로 갱신합니다.
fabric-ca-client identity modify user1 --type peer
다음은 ID 'user1'의 maxenrollments를 5로 갱신합니다.
fabric-ca-client identity modify user1 --maxenrollments 5
maxenrollments 값을 '-2'로 지정하면 ID 'user1'이 CA의 최대 등록 설정을 사용하게됩니다.
fabric-ca-client identity modify user1 --maxenrollments -2
다음은 identity 'user1'에 대한 'hf.Revoker'속성의 값을 'false'로 설정합니다. ID에 다른 속성이 있으면 변경되지 않습니다. ID가 이전에 'hf.Revoker'속성을 소유하지 않은 경우, 속성이 ID에 추가됩니다. 속성은 속성 값을 지정하지 않아도 제거 될 수 있습니다.
fabric-ca-client identity modify user1 --attrs hf.Revoker=false
다음은 'user1'사용자에 대한 'hf.Revoker'속성을 제거합니다.
fabric-ca-client identity modify user1 --attrs hf.Revoker=
다음은 하나의 명령 에서 여러 옵션을 사용할 수 있음을 보여줍니다 . 이 경우 비밀과 유형 모두 사용자 'user1'에 대해 업데이트됩니다.
fabric-ca-client identity modify user1 --secret newpass --type peer
신원 제거
다음은 ID 'user1'을 제거하고 'user1'ID와 연관된 모든 인증서를 취소합니다.
fabric-ca-client identity remove user1
참고 : 기본적으로 fabric-ca-server에서 신원 제거는 비활성화되지만 옵션을 사용하여 fabric-ca-server를 시작하면 활성화 될 수 있습니다 .
소속 관계를 동적으로 업데이트
이 절에서는 fabric-ca-client를 사용하여 소속을 동적으로 업데이트하는 방법에 대해 설명합니다. 다음은 소속을 추가, 수정, 제거 및 나열하는 방법을 보여줍니다.
소속 추가
클라이언트 ID가 다음을 모두 만족시키지 않으면 인증 실패가 발생합니다.
다음은 'org1.dept1'이라는 새로운 소속을 추가합니다.
fabric-ca-client affiliation add org1.dept1
소속 수정
클라이언트 ID가 다음을 모두 만족시키지 않으면 인증 실패가 발생합니다.
다음은 'org2'소속의 이름을 'org3'으로 변경합니다. 또한 하위 소속의 이름을 바꿉니다 (예 : 'org2.department1'이 'org3.department1'로 이름 변경됨).
fabric-ca-client affiliation modify org2 --name org3
소속의 이름 변경에 영향을받는 ID가있는 경우 '-force'옵션을 사용하지 않으면 오류가 발생합니다. '-force'옵션을 사용하면 영향을받는 ID의 소속을 업데이트하여 새 소속 이름을 사용할 수 있습니다.
fabric-ca-client affiliation modify org1 --name org2 --force
소속 관계 제거
클라이언트 ID가 다음을 모두 만족시키지 않으면 인증 실패가 발생합니다.
다음은 소속 'org2'와 하위 소속을 제거합니다. 예를 들어 'org2.dept1'이 'org2'아래의 소속 인 경우에도 제거됩니다.
fabric-ca-client affiliation remove org2
합병의 제거에 영향을받는 ID가있는 경우 '-force'옵션을 사용하지 않으면 오류가 발생합니다. '-force'옵션을 사용하면 해당 소속과 관련된 모든 ID와 이러한 ID와 관련된 인증서가 제거됩니다.
참고 : 소속 제거는 기본적으로 fabric-ca-server에서 비활성화되지만 옵션을 사용하여 fabric-ca-server를 시작하면 활성화 될 수 있습니다 .
소속 정보 나열
클라이언트 ID가 다음을 모두 만족시키지 않으면 인증 실패가 발생합니다.
다음 명령은 특정 소속을 얻는 방법을 보여줍니다.
fabric-ca-client affiliation list --affiliation org2.dept1
호출자는 다음 명령을 실행하여 볼 수있는 권한이있는 모든 소속에 대한 정보를 검색하도록 요청할 수도 있습니다.
fabric-ca-client affiliation list
인증서 관리
이 절에서는 fabric-ca-client를 사용하여 인증서를 관리하는 방법에 대해 설명합니다. 다음은 인증서를 나열하고 삭제하는 방법을 보여줍니다.
인증서 정보 나열
발신자가 볼 수있는 인증서는 다음과 같습니다.
둘 이상의 ID 인증서를 요청하는 list 명령을 실행하는 경우 호출자의 소속과 같거나 그보다 더 가까운 소속이있는 ID의 인증서 만 나열됩니다.
나열된 인증서는 ID, AKI, 일련 번호, 만료 시간 및 / 또는 폐기 시간을 기준으로 필터링 될 수 있습니다.
ID :이 등록 ID의 인증서 나열 일련 번호 :이 일련 번호가있는 인증서 나열 AKI :이 AKI 만료 시간이있는 인증서 나열 : 만료 날짜가 만료 시간 인 인증서를 나열합니다. 해지 시간 : 해지 된 인증서를 나열합니다. 이 해지 시간
결과를 더 자세히 필터링 할 수있는 두 가지 필터가 있습니다. 해지 된 인증서를 반환하지 않거나 만료 된 인증서를 반환하지 않도록 선택할 수 있습니다. 예를 들어 만료되었지만 해지되지 않은 인증서 만 신경 쓰는 경우이 필터를 사용하여 이러한 결과를 되돌릴 수 있습니다. 이 경우의 예가 아래에 나와 있습니다.
시간은 RFC3339에 따라 지정해야합니다. 예를 들어 2018 년 3 월 1 일 오후 1 시부 터 2018 년 6 월 15 일 2시에 만료되는 인증서를 나열하려면 입력 된 시간 문자열이 2018-03-01T13 : 00 : 00z 및 2018-06과 같이 표시됩니다. -15T02 : 00 : 00z. 시간이 중요하지 않고 날짜 만 중요한 경우 시간 부분을 남겨두고 문자열은 2018-03-01 및 2018-06-15가됩니다.
다음 명령은 다양한 필터를 사용하여 인증서를 나열하는 방법을 보여줍니다.
모든 인증서 나열 :
fabric-ca-client certificate list --id admin
id가 제공하는 모든 인증순보기 :
fabric-ca-client certificate list --serial 1234 --aki 1234
시리얼 및 아키에 의한 인증서 목록 :
fabric-ca-client certificate list --id admin --serial 1234 --aki 1234
ID와 시리얼 / 아키에 의한 인증서 목록 :
fabric-ca-client certificate list --id admin --notrevoked --notexpired
revoker가 아니거나 만료 된 인증서를 ID별로 나열하십시오.
fabric-ca-client certificate list –id admin –notrevoked
id (admin)에 대해 취소되지 않은 모든 인증서 나열 : code :: bash
모든 인증서가 id (admin)에 대해 만료되지 않았 음을 나열하십시오.
"-notexpired"플래그는 "-expiration now ::"와 동일합니다. 즉 인증서가 앞으로 만료 될 것임을 의미합니다.
fabric-ca-client certificate list --id admin --notexpired
ID (admin)의 시간 범위에서 취소 된 모든 인증서 나열 :
fabric-ca-client certificate list --id admin --revocation 2018-01-01T01:30:00z::2018-01-30T05:00:00z
시간 범위 사이에 취소되었지만 만료되지 않은 모든 인증서를 ID (admin)로 나열하십시오.
fabric-ca-client certificate list --id admin --revocation 2018-01-01::2018-01-30 --notexpired
id (admin)에 대해 기간 (30 일에서 15 일 전에 취소)을 사용하여 모든 취소 된 인증서를 나열합니다.
fabric-ca-client certificate list --id admin --revocation -30d::-15d
시간 전에 모든 취소 된 인증서를 나열하십시오.
fabric-ca-client certificate list --revocation ::2018-01-30한 번 후에 폐기 된 모든 인증서 나열
fabric-ca-client certificate list --revocation 2018-01-30::
특정 날짜 이후의 모든 취소 된 인증서 나열
fabric-ca-client certificate list --id admin --revocation 2018-01-30::now
시간 범위 사이에 만료되었지만 ID (admin)에 대해 해지되지 않은 모든 인증서 나열 :
fabric-ca-client certificate list --id admin --expiration 2018-01-01::2018-01-30 --notrevoked
id (admin)의 기간 (30 일에서 15 일 전에 만료 됨)을 사용하여 만료 된 모든 인증서를 나열합니다.
fabric-ca-client certificate list --expiration -30d::-15d
특정 시간 전에 만료되었거나 만료되는 모든 인증서 나열
fabric-ca-client certificate list --expiration ::2058-01-30특정 기간 후에 만료되었거나 만료되는 모든 인증서 나열
fabric-ca-client certificate list --expiration 2018-01-30::
특정 날짜 이후의 모든 만료 된 인증서 나열
fabric-ca-client certificate list --expiration 2018-01-30::now
다음 10 일 내에 만료되는 인증서 나열 :
fabric-ca-client certificate list --id admin --expiration ::+10d --notrevoked특정 CA 인스턴스에 컨택
서버에서 여러 CA 인스턴스를 실행하는 경우 특정 CA로 요청을 보낼 수 있습니다.
기본적으로 클라이언트 요청에 CA 이름이 지정되지 않은 경우 요청은 fabric-ca 서버의 기본 CA로 전달됩니다.
CA 이름은 클라이언트 명령의 명령 행에서 다음과 같이 지정할 수 있습니다.
fabric-ca-client enroll -u http://admin:adminpw@localhost:7054 --caname <caname>
HSM
기본적으로 패브릭 CA 서버 및 클라이언트는 개인 키를 PEM 인코딩 파일에 저장하지만 PKCS11 API를 통해 개인 키를 HSM (하드웨어 보안 모듈)에 저장하도록 구성 할 수도 있습니다.
이 동작은 서버 또는 클라이언트 구성 파일의 BCCSP (BlockChain Crypto Service Provider) 섹션에서 구성됩니다.
softhsm2를 사용하도록 Fabric CA 서버 구성
이 절에서는 softhsm이라는 소프트웨어 버전의 PKCS11 ( https://github.com/opendnssec/SoftHSMv2 참조 ) 을 사용하도록 Fabric CA 서버 또는 클라이언트를 구성하는 방법을 보여줍니다 .
softhsm을 설치 한 후 토큰을 만들고 "ForFabric"레이블을 지정하고 핀을 '98765432'로 설정하십시오 (softhsm 문서 참조).
구성 파일과 환경 변수를 모두 사용하여 BCCSP를 구성 할 수 있습니다. 예를 들어 Fabric CA 서버 구성 파일의 bccsp 섹션을 다음과 같이 설정하십시오. 기본 필드 값은 PKCS11입니다.
#############################################################################
# BCCSP (BlockChain Crypto Service Provider) section is used to select which
# crypto library implementation to use
#############################################################################
bccsp:
default: PKCS11
pkcs11:
Library: /usr/local/Cellar/softhsm/2.1.0/lib/softhsm/libsofthsm2.so
Pin: 98765432
Label: ForFabric
hash: SHA2
security: 256
filekeystore:
# The directory used for the software file-based keystore
keystore: msp/keystore
그리고 다음과 같이 환경 변수를 통해 관련 필드를 재정의 할 수 있습니다.
FABRIC_CA_SERVER_BCCSP_DEFAULT = PKCS11
FABRIC_CA_SERVER_BCCSP_PKCS11_LIBRARY = / usr / local / Cellar / softhsm / 2.1.0 / lib / softhsm / libsofthsm2.so
FABRIC_CA_SERVER_BCCSP_PKCS11_PIN = 98765432
FABRIC_CA_SERVER_BCCSP_PKCS11_LABEL = ForFabric
파일 형식
패브릭 CA 서버의 구성 파일 형식
기본 구성 파일은 서버의 홈 디렉토리에 생성됩니다 (자세한 내용은 Fabric CA 서버 섹션 참조 ). 다음 링크는 샘플 Server 구성 파일을 보여줍니다 .
패브릭 CA 클라이언트의 구성 파일 형식
클라이언트의 홈 디렉토리에 기본 구성 파일이 생성됩니다 (자세한 내용은 Fabric CA 클라이언트 섹션 참조 ). 다음 링크는 샘플 클라이언트 구성 파일을 보여줍니다 .
출처 : http://hyperledger-fabric-ca.readthedocs.io/en/latest/users-guide.html
'[블록체인] 하이퍼레저 > [하이퍼레저 패브릭] ' 카테고리의 다른 글
| [하이퍼레저 공식문서]Key Concepts - Hyperledger Fabric model (0) | 2018.06.04 |
|---|---|
| [하이퍼레저 공식문서]Key Concepts - Hyperledger Fabric Functionalities (0) | 2018.06.04 |
| [하이퍼레저 공식문서]Ordering Service FAQ - BFT (0) | 2018.06.04 |
| [하이퍼레저 공식문서]Ordering Service FAQ - Kafka (0) | 2018.06.04 |
| [하이퍼레저 공식문서]Ordering Service FAQ - Solo (0) | 2018.06.04 |