خرید سایت

آرتا رسانه

برنامه Spring Boot Full stack Blockchain با Hyperledger Fabric در Kubernetes (قسمت 3)

جدول محتوا

از سری مقالات ادغام Hyperledger Fabric با Spring Boot در این مقاله، به بررسی Fabric CA Server و نصب Fabric CA Server در Kubernetes می پردازیم.

سایر مقالات در مورد ادغام Hyperledger Fabric با Spring Boot از لینک های زیر قابل دسترسی هستند.

بخش 1 – مقدمه

قسمت 2 – راه اندازی خوشه Kubernetes

قسمت 3- Fabric CA Server

بخش 4 – تولید گواهینامه ها و مصنوعات

قسمت پنجم – Kafka

قسمت 6 – سفارش دهنده

Fabric CA Server چیست؟
Fabric CA یک مرجع صدور گواهی (CA) برای Hyperledger Fabric است.

امکاناتی مانند:

ثبت هویت، یا به عنوان رجیستری کاربر به LDAP متصل می شود
صدور گواهی ثبت نام (ECerts)
تمدید و ابطال گواهینامه
نمودار زیر نشان می دهد که چگونه سرور Hyperledger Fabric CA در معماری کلی Hyperledger Fabric قرار می گیرد.

ادغام Hyperledger Fabric با Spring Boot

دو راه برای تعامل با سرور Hyperledger Fabric CA وجود دارد: از طریق کلاینت Hyperledger Fabric CA یا از طریق یکی از Fabric SDK. تمام ارتباط با سرور Hyperledger Fabric CA از طریق API های REST است.

کلاینت Hyperledger Fabric CA یا SDK ممکن است به سروری در خوشه ای از سرورهای Hyperledger Fabric CA متصل شود. این در قسمت بالا سمت راست نمودار نشان داده شده است. کلاینت به یک نقطه پایانی پروکسی HA هدایت می شود که بار ترافیک را به یکی از اعضای خوشه فابریک-ca-server متعادل می کند.

یک سرور ممکن است حاوی چندین CA باشد. هر CA یا یک CA ریشه یا یک CA میانی است. هر CA واسطه دارای یک CA والد است که یا یک CA ریشه یا یک CA واسطه دیگر است.

پیکربندی Fabric CA Server

آموزش ادغام Hyperledger Fabric با Spring Boot

بیایید پروژه ای را که دانلود کردیم از این لینک باز کنیم و به دایرکتوری که ca در آن قرار دارد برویم.

$ cd deploy/k8s

تنظیمات پیکربندی

Fabric CA 3 راه برای پیکربندی تنظیمات روی سرور Fabric CA و کلاینت ارائه می دهد. ترتیب تقدم عبارت است از:

1. پرچم های CLI

2. متغیرهای محیطی

3. فایل پیکربندی

ما سرور فابریک ca را با فایل پیکربندی پیکربندی می کنیم.

ما 4 Fabric CAserver را برای سفارش دهنده، org1، org2 و org3 راه اندازی می کنیم.لازم است برای هر سرور Fabric CA یک فایل پیکربندی تعریف شود.

فایل پیکربندی Fabric CA که در پروژه برای Orderer تعریف شده است به شرح زیر است فایل پیکربندی در پوشه deploy/k8s/fabricfiles/organizations/fabric-ca/ordererOrg قرار دارد.

############################################################################# # This is a configuration file for the fabric-ca-server command. # # COMMAND LINE ARGUMENTS AND ENVIRONMENT VARIABLES # ------------------------------------------------ # Each configuration element can be overridden via command line # arguments or environment variables. The precedence for determining # the value of each element is as follows: # 1) command line argument # Examples: # a) --port 443 # To set the listening port # b) --ca.keyfile ../mykey.pem # To set the "keyfile" element in the "ca" section below; # note the '.' separator character. # 2) environment variable # Examples: # a) FABRIC_CA_SERVER_PORT=443 # To set the listening port # b) FABRIC_CA_SERVER_CA_KEYFILE="../mykey.pem" # To set the "keyfile" element in the "ca" section below; # note the '_' separator character. # 3) configuration file # 4) default value (if there is one) # All default values are shown beside each element below. # # FILE NAME ELEMENTS # ------------------ # The value of all fields whose name ends with "file" or "files" are # name or names of other files. # For example, see "tls.certfile" and "tls.clientauth.certfiles". # The value of each of these fields can be a simple filename, a # relative path, or an absolute path. If the value is not an # absolute path, it is interpretted as being relative to the location # of this configuration file. # ############################################################################# # Version of config file version: 1.2.0 # Server's listening port (default: 7054) port: 7054 # Enables debug logging (default: false) debug: false # Size limit of an acceptable CRL in bytes (default: 512000) crlsizelimit: 512000 ############################################################################# # TLS section for the server's listening port # # The following types are supported for client authentication: NoClientCert, # RequestClientCert, RequireAnyClientCert, VerifyClientCertIfGiven, # and RequireAndVerifyClientCert. # # Certfiles is a list of root certificate authorities that the server uses # when verifying client certificates. ############################################################################# tls: # Enable TLS (default: false) enabled: true # TLS for the server's listening port certfile: keyfile: clientauth: type: noclientcert certfiles: ############################################################################# # The CA section contains information related to the Certificate Authority # including the name of the CA, which should be unique for all members # of a blockchain network. It also includes the key and certificate files # used when issuing enrollment certificates (ECerts) and transaction # certificates (TCerts). # The chainfile (if it exists) contains the certificate chain which # should be trusted for this CA, where the 1st in the chain is always the # root CA certificate. ############################################################################# ca: # Name of this CA name: OrdererCA # Key file (is only used to import a private key into BCCSP) keyfile: # Certificate file (default: ca-cert.pem) certfile: # Chain file chainfile: ############################################################################# # The gencrl REST endpoint is used to generate a CRL that contains revoked # certificates. This section contains configuration options that are used # during gencrl request processing. ############################################################################# crl: # Specifies expiration for the generated CRL. The number of hours # specified by this property is added to the UTC time, the resulting time # is used to set the 'Next Update' date of the CRL. expiry: 24h ############################################################################# # The registry section controls how the fabric-ca-server does two things: # 1) authenticates enrollment requests which contain a username and password # (also known as an enrollment ID and secret). # 2) once authenticated, retrieves the identity's attribute names and # values which the fabric-ca-server optionally puts into TCerts # which it issues for transacting on the Hyperledger Fabric blockchain. # These attributes are useful for making access control decisions in # chaincode. # There are two main configuration options: # 1) The fabric-ca-server is the registry. # This is true if "ldap.enabled" in the ldap section below is false. # 2) An LDAP server is the registry, in which case the fabric-ca-server # calls the LDAP server to perform these tasks. # This is true if "ldap.enabled" in the ldap section below is true, # which means this "registry" section is ignored. ############################################################################# registry: # Maximum number of times a password/secret can be reused for enrollment # (default: -1, which means there is no limit) maxenrollments: -1 # Contains identity information which is used when LDAP is disabled identities: - name: admin pass: adminpw type: client affiliation: "" attrs: hf.Registrar.Roles: "*" hf.Registrar.DelegateRoles: "*" hf.Revoker: true hf.IntermediateCA: true hf.GenCRL: true hf.Registrar.Attributes: "*" hf.AffiliationMgr: true ############################################################################# # Database section # Supported types are: "sqlite3", "postgres", and "mysql". # The datasource value depends on the type. # If the type is "sqlite3", the datasource value is a file name to use # as the database store. Since "sqlite3" is an embedded database, it # may not be used if you want to run the fabric-ca-server in a cluster. # To run the fabric-ca-server in a cluster, you must choose "postgres" # or "mysql". ############################################################################# db: type: sqlite3 datasource: fabric-ca-server.db tls: enabled: false certfiles: client: certfile: keyfile: ############################################################################# # LDAP section # If LDAP is enabled, the fabric-ca-server calls LDAP to: # 1) authenticate enrollment ID and secret (i.e. username and password) # for enrollment requests; # 2) To retrieve identity attributes ############################################################################# ldap: # Enables or disables the LDAP client (default: false) # If this is set to true, the "registry" section is ignored. enabled: false # The URL of the LDAP server url: ldap://:@:/ # TLS configuration for the client connection to the LDAP server tls: certfiles: client: certfile: keyfile: # Attribute related configuration for mapping from LDAP entries to Fabric CA attributes attribute: # 'names' is an array of strings containing the LDAP attribute names which are # requested from the LDAP server for an LDAP identity's entry names: ['uid','member'] # The 'converters' section is used to convert an LDAP entry to the value of # a fabric CA attribute. # 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 boolean expression # evaluates to true). # converters: # - name: hf.Revoker # value: attr("uid") =~ "revoker*" converters: - name: value: # The 'maps' section contains named maps which may be referenced by the 'map' # function in the 'converters' section to map LDAP responses to arbitrary values. # For example, assume a user has an LDAP attribute named 'member' which has multiple # values which are each a distinguished name (i.e. a DN). For simplicity, assume the # values of the 'member' attribute are 'dn1', 'dn2', and 'dn3'. # Further assume the following configuration. # converters: # - name: hf.Registrar.Roles # value: map(attr("member"),"groups") # maps: # groups: # - name: dn1 # value: peer # - name: dn2 # value: client # The value of the user's 'hf.Registrar.Roles' attribute is then computed to be # "peer,client,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 "peer" and "dn2" with "client". maps: groups: - name: value: ############################################################################# # Affiliations section. Fabric CA server can be bootstrapped with the # affiliations specified in this section. Affiliations are specified as maps. # For example: # businessunit1: # department1: # - team1 # businessunit2: # - department2 # - department3 # # Affiliations are hierarchical in nature. In the above example, # department1 (used as businessunit1.department1) is the child of businessunit1. # team1 (used as businessunit1.department1.team1) is the child of department1. # department2 (used as businessunit2.department2) and department3 (businessunit2.department3) # are children of businessunit2. # Note: Affiliations are case sensitive except for the non-leaf affiliations # (like businessunit1, department1, businessunit2) that are specified in the configuration file, # which are always stored in lower case. ############################################################################# affiliations: org1: - department1 - department2 org2: - department1 ############################################################################# # Signing section # # The "default" subsection is used to sign enrollment certificates; # the default expiration ("expiry" field) is "8760h", which is 1 year in hours. # # The "ca" profile subsection is used to sign intermediate CA certificates; # the default expiration ("expiry" field) is "43800h" which is 5 years in hours. # Note that "isca" is true, meaning that it issues a CA certificate. # A maxpathlen of 0 means that the intermediate CA cannot issue other # intermediate CA certificates, though it can still issue end entity certificates. # (See RFC 5280, section 4.2.1.9) # # The "tls" profile subsection is used to sign TLS certificate requests; # the default expiration ("expiry" field) is "8760h", which is 1 year in hours. ############################################################################# signing: default: usage: - digital signature expiry: 8760h profiles: ca: usage: - cert sign - crl sign expiry: 43800h caconstraint: isca: true maxpathlen: 0 tls: usage: - signing - key encipherment - server auth - client auth - key agreement expiry: 8760h ########################################################################### # Certificate Signing Request (CSR) section. # This controls the creation of the root CA certificate. # The expiration for the root CA certificate is configured with the # "ca.expiry" field below, whose default value is "131400h" which is # 15 years in hours. # The pathlength field is used to limit CA certificate hierarchy as described # in section 4.2.1.9 of RFC 5280. # Examples: # 1) No pathlength value means no limit is requested. # 2) pathlength == 1 means a limit of 1 is requested which is the default for # a root CA. This means the root CA can issue intermediate CA certificates, # but these intermediate CAs may not in turn issue other CA certificates # though they can still issue end entity certificates. # 3) pathlength == 0 means a limit of 0 is requested; # this is the default for an intermediate CA, which means it can not issue # CA certificates though it can still issue end entity certificates. ########################################################################### csr: cn: ca-org1 names: - C: US ST: "New York" L: "New York" O: example.com OU: hosts: - localhost - example.com - ca-orderer ca: expiry: 131400h pathlength: 1 ############################################################################# # BCCSP (BlockChain Crypto Service Provider) section is used to select which # crypto library implementation to use ############################################################################# bccsp: default: SW sw: hash: SHA2 security: 256 filekeystore: # The directory used for the software file-based keystore keystore: msp/keystore ############################################################################# # Multi CA section # # Each Fabric CA server contains one CA by default. This section is used # to configure multiple CAs in a single server. # # 1) --cacount # Automatically generate non-default CAs. The names of these # additional CAs are "ca1", "ca2", ... "caN", where "N" is # This is particularly useful in a development environment to quickly set up # multiple CAs. Note that, this config option is not applicable to intermediate CA server # i.e., Fabric CA server that is started with intermediate.parentserver.url config # option (-u command line option) # # 2) --cafiles # For each CA config file in the list, generate a separate signing CA. Each CA # config file in this list MAY contain all of the same elements as are found in # the server config file except port, debug, and tls sections. # # Examples: # fabric-ca-server start -b admin:adminpw --cacount 2 # # fabric-ca-server start -b admin:adminpw --cafiles ca/ca1/fabric-ca-server-config.yaml # --cafiles ca/ca2/fabric-ca-server-config.yaml # ############################################################################# cacount: cafiles: ############################################################################# # Intermediate CA section # # The relationship between servers and CAs is as follows: # 1) A single server process may contain or function as one or more CAs. # This is configured by the "Multi CA section" above. # 2) Each CA is either a root CA or an intermediate CA. # 3) Each intermediate CA has a parent CA which is either a root CA or another intermediate CA. # # This section pertains to configuration of #2 and #3. # If the "intermediate.parentserver.url" property is set, # then this is an intermediate CA with the specified parent # CA. # # parentserver section # url - The URL of the parent server # caname - Name of the CA to enroll within the server # # enrollment section used to enroll intermediate CA with parent CA # profile - Name of the signing profile to use in issuing the certificate # label - Label to use in HSM operations # # tls section for secure socket connection # certfiles - PEM-encoded list of trusted root certificate files # client: # certfile - PEM-encoded certificate file for when client authentication # is enabled on server # keyfile - PEM-encoded key file for when client authentication # is enabled on server ############################################################################# intermediate: parentserver: url: caname: enrollment: hosts: profile: label: tls: certfiles: client: certfile: keyfile:
csr: ... hosts: - localhost - example.com - ca-orderer

localhost،example.com،ca-orderer به عنوان میزبان csr به فایل پیکربندی اضافه شد.

ca-orderer نام سرویس فابریک سرور ca در kubernetes است.

ca: # Name of this CA name: OrdererCA

OrdererCA نام CA است.

csr: cn: ca-org1 names: - C: US ST: "New York" L: "New York" O: ca-org1 OU: ca-org1

تمام فیلدهای بالا مربوط به کلید امضای X.509 و گواهی است که توسط فابریک-ca-server init تولید می شود. این مربوط به فایل‌های ca.certfile و ca.keyfile در فایل پیکربندی سرور است. فیلدها به شرح زیر است:

cn نام مشترک است
O نام سازمان است
OU واحد سازمانی است
L مکان یا شهر است
ST ایالت است
C کشور است

registry: ... identities: - name: admin pass: adminpw type: client affiliation: ""

باید با حداقل یک هویت بوت استرپ از پیش ثبت شده پیکربندی شود تا شما را قادر سازد تا هویت های دیگر را ثبت کنید.گزینه -b نام و رمز عبور هویت بوت استرپ را مشخص می کند.

db: type: sqlite3 datasource: fabric-ca-server.db

پایگاه داده پیش فرض SQLite است و فایل پایگاه داده پیش فرض پارچه-ca-server.db در فهرست اصلی سرور Fabric CA است. سرور Fabric CA همچنین می تواند به پایگاه داده PostgreSQL یا MySQL متصل شود.

Fabric CA از نسخه های پایگاه داده زیر در راه اندازی کلاستر پشتیبانی می کند:

PostgreSQL: 9.5.5 یا بالاتر
MySQL: 5.7 یا بالاتر

affiliations: org1: - department1 - department2 org2: - department1

من به وابستگی ها به عنوان برچسب های سلسله مراتبی فکر می کنم. هر هویت را می توان به یک وابستگی در سلسله مراتب برچسب (وابسته) کرد. وقتی هویتی با یک وابستگی مرتبط است، به آن و همه وابستگی های فرزند وابسته است. وابستگی ها در حال حاضر در هنگام ثبت نام و ابطال استفاده می شوند.

فایل پیکربندی Fabric CA که در پروژه برای Org1 تعریف شده است به صورت زیر است فایل پیکربندی در پوشه deploy/k8s/fabricfiles/organizations/fabric-ca/org1 قرار دارد.

############################################################################# # This is a configuration file for the fabric-ca-server command. # # COMMAND LINE ARGUMENTS AND ENVIRONMENT VARIABLES # ------------------------------------------------ # Each configuration element can be overridden via command line # arguments or environment variables. The precedence for determining # the value of each element is as follows: # 1) command line argument # Examples: # a) --port 443 # To set the listening port # b) --ca.keyfile ../mykey.pem # To set the "keyfile" element in the "ca" section below; # note the '.' separator character. # 2) environment variable # Examples: # a) FABRIC_CA_SERVER_PORT=443 # To set the listening port # b) FABRIC_CA_SERVER_CA_KEYFILE="../mykey.pem" # To set the "keyfile" element in the "ca" section below; # note the '_' separator character. # 3) configuration file # 4) default value (if there is one) # All default values are shown beside each element below. # # FILE NAME ELEMENTS # ------------------ # The value of all fields whose name ends with "file" or "files" are # name or names of other files. # For example, see "tls.certfile" and "tls.clientauth.certfiles". # The value of each of these fields can be a simple filename, a # relative path, or an absolute path. If the value is not an # absolute path, it is interpretted as being relative to the location # of this configuration file. # ############################################################################# # Version of config file version: 1.2.0 # Server's listening port (default: 7054) port: 7054 # Enables debug logging (default: false) debug: false # Size limit of an acceptable CRL in bytes (default: 512000) crlsizelimit: 512000 ############################################################################# # TLS section for the server's listening port # # The following types are supported for client authentication: NoClientCert, # RequestClientCert, RequireAnyClientCert, VerifyClientCertIfGiven, # and RequireAndVerifyClientCert. # # Certfiles is a list of root certificate authorities that the server uses # when verifying client certificates. ############################################################################# tls: # Enable TLS (default: false) enabled: true # TLS for the server's listening port certfile: keyfile: clientauth: type: noclientcert certfiles: ############################################################################# # The CA section contains information related to the Certificate Authority # including the name of the CA, which should be unique for all members # of a blockchain network. It also includes the key and certificate files # used when issuing enrollment certificates (ECerts) and transaction # certificates (TCerts). # The chainfile (if it exists) contains the certificate chain which # should be trusted for this CA, where the 1st in the chain is always the # root CA certificate. ############################################################################# ca: # Name of this CA name: Org1CA # Key file (is only used to import a private key into BCCSP) keyfile: # Certificate file (default: ca-cert.pem) certfile: # Chain file chainfile: ############################################################################# # The gencrl REST endpoint is used to generate a CRL that contains revoked # certificates. This section contains configuration options that are used # during gencrl request processing. ############################################################################# crl: # Specifies expiration for the generated CRL. The number of hours # specified by this property is added to the UTC time, the resulting time # is used to set the 'Next Update' date of the CRL. expiry: 24h ############################################################################# # The registry section controls how the fabric-ca-server does two things: # 1) authenticates enrollment requests which contain a username and password # (also known as an enrollment ID and secret). # 2) once authenticated, retrieves the identity's attribute names and # values which the fabric-ca-server optionally puts into TCerts # which it issues for transacting on the Hyperledger Fabric blockchain. # These attributes are useful for making access control decisions in # chaincode. # There are two main configuration options: # 1) The fabric-ca-server is the registry. # This is true if "ldap.enabled" in the ldap section below is false. # 2) An LDAP server is the registry, in which case the fabric-ca-server # calls the LDAP server to perform these tasks. # This is true if "ldap.enabled" in the ldap section below is true, # which means this "registry" section is ignored. ############################################################################# registry: # Maximum number of times a password/secret can be reused for enrollment # (default: -1, which means there is no limit) maxenrollments: -1 # Contains identity information which is used when LDAP is disabled identities: - name: admin pass: adminpw type: client affiliation: "" attrs: hf.Registrar.Roles: "*" hf.Registrar.DelegateRoles: "*" hf.Revoker: true hf.IntermediateCA: true hf.GenCRL: true hf.Registrar.Attributes: "*" hf.AffiliationMgr: true ############################################################################# # Database section # Supported types are: "sqlite3", "postgres", and "mysql". # The datasource value depends on the type. # If the type is "sqlite3", the datasource value is a file name to use # as the database store. Since "sqlite3" is an embedded database, it # may not be used if you want to run the fabric-ca-server in a cluster. # To run the fabric-ca-server in a cluster, you must choose "postgres" # or "mysql". ############################################################################# db: type: sqlite3 datasource: fabric-ca-server.db tls: enabled: false certfiles: client: certfile: keyfile: ############################################################################# # LDAP section # If LDAP is enabled, the fabric-ca-server calls LDAP to: # 1) authenticate enrollment ID and secret (i.e. username and password) # for enrollment requests; # 2) To retrieve identity attributes ############################################################################# ldap: # Enables or disables the LDAP client (default: false) # If this is set to true, the "registry" section is ignored. enabled: false # The URL of the LDAP server url: ldap://:@:/ # TLS configuration for the client connection to the LDAP server tls: certfiles: client: certfile: keyfile: # Attribute related configuration for mapping from LDAP entries to Fabric CA attributes attribute: # 'names' is an array of strings containing the LDAP attribute names which are # requested from the LDAP server for an LDAP identity's entry names: ['uid','member'] # The 'converters' section is used to convert an LDAP entry to the value of # a fabric CA attribute. # 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 boolean expression # evaluates to true). # converters: # - name: hf.Revoker # value: attr("uid") =~ "revoker*" converters: - name: value: # The 'maps' section contains named maps which may be referenced by the 'map' # function in the 'converters' section to map LDAP responses to arbitrary values. # For example, assume a user has an LDAP attribute named 'member' which has multiple # values which are each a distinguished name (i.e. a DN). For simplicity, assume the # values of the 'member' attribute are 'dn1', 'dn2', and 'dn3'. # Further assume the following configuration. # converters: # - name: hf.Registrar.Roles # value: map(attr("member"),"groups") # maps: # groups: # - name: dn1 # value: peer # - name: dn2 # value: client # The value of the user's 'hf.Registrar.Roles' attribute is then computed to be # "peer,client,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 "peer" and "dn2" with "client". maps: groups: - name: value: ############################################################################# # Affiliations section. Fabric CA server can be bootstrapped with the # affiliations specified in this section. Affiliations are specified as maps. # For example: # businessunit1: # department1: # - team1 # businessunit2: # - department2 # - department3 # # Affiliations are hierarchical in nature. In the above example, # department1 (used as businessunit1.department1) is the child of businessunit1. # team1 (used as businessunit1.department1.team1) is the child of department1. # department2 (used as businessunit2.department2) and department3 (businessunit2.department3) # are children of businessunit2. # Note: Affiliations are case sensitive except for the non-leaf affiliations # (like businessunit1, department1, businessunit2) that are specified in the configuration file, # which are always stored in lower case. ############################################################################# affiliations: org1: - department1 - department2 org2: - department1 org3: - department1 ############################################################################# # Signing section # # The "default" subsection is used to sign enrollment certificates; # the default expiration ("expiry" field) is "8760h", which is 1 year in hours. # # The "ca" profile subsection is used to sign intermediate CA certificates; # the default expiration ("expiry" field) is "43800h" which is 5 years in hours. # Note that "isca" is true, meaning that it issues a CA certificate. # A maxpathlen of 0 means that the intermediate CA cannot issue other # intermediate CA certificates, though it can still issue end entity certificates. # (See RFC 5280, section 4.2.1.9) # # The "tls" profile subsection is used to sign TLS certificate requests; # the default expiration ("expiry" field) is "8760h", which is 1 year in hours. ############################################################################# signing: default: usage: - digital signature expiry: 8760h profiles: ca: usage: - cert sign - crl sign expiry: 43800h caconstraint: isca: true maxpathlen: 0 tls: usage: - signing - key encipherment - server auth - client auth - key agreement expiry: 8760h ########################################################################### # Certificate Signing Request (CSR) section. # This controls the creation of the root CA certificate. # The expiration for the root CA certificate is configured with the # "ca.expiry" field below, whose default value is "131400h" which is # 15 years in hours. # The pathlength field is used to limit CA certificate hierarchy as described # in section 4.2.1.9 of RFC 5280. # Examples: # 1) No pathlength value means no limit is requested. # 2) pathlength == 1 means a limit of 1 is requested which is the default for # a root CA. This means the root CA can issue intermediate CA certificates, # but these intermediate CAs may not in turn issue other CA certificates # though they can still issue end entity certificates. # 3) pathlength == 0 means a limit of 0 is requested; # this is the default for an intermediate CA, which means it can not issue # CA certificates though it can still issue end entity certificates. ########################################################################### csr: cn: ca-org1 names: - C: US ST: "New York" L: "New York" O: ca-org1 OU: ca-org1 hosts: - localhost - example.com - ca-org1 ca: expiry: 131400h pathlength: 1 ############################################################################# # BCCSP (BlockChain Crypto Service Provider) section is used to select which # crypto library implementation to use ############################################################################# bccsp: default: SW sw: hash: SHA2 security: 256 filekeystore: # The directory used for the software file-based keystore keystore: msp/keystore ############################################################################# # Multi CA section # # Each Fabric CA server contains one CA by default. This section is used # to configure multiple CAs in a single server. # # 1) --cacount # Automatically generate non-default CAs. The names of these # additional CAs are "ca1", "ca2", ... "caN", where "N" is # This is particularly useful in a development environment to quickly set up # multiple CAs. Note that, this config option is not applicable to intermediate CA server # i.e., Fabric CA server that is started with intermediate.parentserver.url config # option (-u command line option) # # 2) --cafiles # For each CA config file in the list, generate a separate signing CA. Each CA # config file in this list MAY contain all of the same elements as are found in # the server config file except port, debug, and tls sections. # # Examples: # fabric-ca-server start -b admin:adminpw --cacount 2 # # fabric-ca-server start -b admin:adminpw --cafiles ca/ca1/fabric-ca-server-config.yaml # --cafiles ca/ca2/fabric-ca-server-config.yaml # ############################################################################# cacount: cafiles: ############################################################################# # Intermediate CA section # # The relationship between servers and CAs is as follows: # 1) A single server process may contain or function as one or more CAs. # This is configured by the "Multi CA section" above. # 2) Each CA is either a root CA or an intermediate CA. # 3) Each intermediate CA has a parent CA which is either a root CA or another intermediate CA. # # This section pertains to configuration of #2 and #3. # If the "intermediate.parentserver.url" property is set, # then this is an intermediate CA with the specified parent # CA. # # parentserver section # url - The URL of the parent server # caname - Name of the CA to enroll within the server # # enrollment section used to enroll intermediate CA with parent CA # profile - Name of the signing profile to use in issuing the certificate # label - Label to use in HSM operations # # tls section for secure socket connection # certfiles - PEM-encoded list of trusted root certificate files # client: # certfile - PEM-encoded certificate file for when client authentication # is enabled on server # keyfile - PEM-encoded key file for when client authentication # is enabled on server ############################################################################# intermediate: parentserver: url: caname: enrollment: hosts: profile: label: tls: certfiles: client: certfile: keyfile:
csr: ... hosts: - localhost - example.com - ca-org1

localhost,example.com,ca-org1 به عنوان میزبان csr به فایل پیکربندی اضافه شد.

ca-org1 نام سرویس فابریک سرور ca در kubernetes است.

ca: # Name of this CA name: Org1CA

Org1CA نام CA است.

csr: cn: ca-org1 names: - C: US ST: "New York" L: "New York" O: ca-org1 OU: ca-org1

تمام فیلدهای بالا مربوط به کلید امضای X. 509 و گواهی است که توسط fabric-ca-server init.

affiliations: org1: - department1 - department2 org2: - department1 org3: - department1

تعاریف وابستگی با فایل پیکربندی CA Orderer متفاوت است. تعاریف Affiliation در Org2 و Org3 اضافه شده است. پایگاه داده و تنظیمات کاربر بوت استرپ مانند ca orderer است.

فایل پیکربندی Fabric CA که در پروژه برای Org2 تعریف شده است به شرح زیر است فایل پیکربندی در پوشه deploy/k8s/fabricfiles/organizations/fabric-ca/org2 قرار دارد.

############################################################################# # This is a configuration file for the fabric-ca-server command. # # COMMAND LINE ARGUMENTS AND ENVIRONMENT VARIABLES # ------------------------------------------------ # Each configuration element can be overridden via command line # arguments or environment variables. The precedence for determining # the value of each element is as follows: # 1) command line argument # Examples: # a) --port 443 # To set the listening port # b) --ca.keyfile ../mykey.pem # To set the "keyfile" element in the "ca" section below; # note the '.' separator character. # 2) environment variable # Examples: # a) FABRIC_CA_SERVER_PORT=443 # To set the listening port # b) FABRIC_CA_SERVER_CA_KEYFILE="../mykey.pem" # To set the "keyfile" element in the "ca" section below; # note the '_' separator character. # 3) configuration file # 4) default value (if there is one) # All default values are shown beside each element below. # # FILE NAME ELEMENTS # ------------------ # The value of all fields whose name ends with "file" or "files" are # name or names of other files. # For example, see "tls.certfile" and "tls.clientauth.certfiles". # The value of each of these fields can be a simple filename, a # relative path, or an absolute path. If the value is not an # absolute path, it is interpretted as being relative to the location # of this configuration file. # ############################################################################# # Version of config file version: 1.2.0 # Server's listening port (default: 7054) port: 7054 # Enables debug logging (default: false) debug: false # Size limit of an acceptable CRL in bytes (default: 512000) crlsizelimit: 512000 ############################################################################# # TLS section for the server's listening port # # The following types are supported for client authentication: NoClientCert, # RequestClientCert, RequireAnyClientCert, VerifyClientCertIfGiven, # and RequireAndVerifyClientCert. # # Certfiles is a list of root certificate authorities that the server uses # when verifying client certificates. ############################################################################# tls: # Enable TLS (default: false) enabled: true # TLS for the server's listening port certfile: keyfile: clientauth: type: noclientcert certfiles: ############################################################################# # The CA section contains information related to the Certificate Authority # including the name of the CA, which should be unique for all members # of a blockchain network. It also includes the key and certificate files # used when issuing enrollment certificates (ECerts) and transaction # certificates (TCerts). # The chainfile (if it exists) contains the certificate chain which # should be trusted for this CA, where the 1st in the chain is always the # root CA certificate. ############################################################################# ca: # Name of this CA name: Org2CA # Key file (is only used to import a private key into BCCSP) keyfile: # Certificate file (default: ca-cert.pem) certfile: # Chain file chainfile: ############################################################################# # The gencrl REST endpoint is used to generate a CRL that contains revoked # certificates. This section contains configuration options that are used # during gencrl request processing. ############################################################################# crl: # Specifies expiration for the generated CRL. The number of hours # specified by this property is added to the UTC time, the resulting time # is used to set the 'Next Update' date of the CRL. expiry: 24h ############################################################################# # The registry section controls how the fabric-ca-server does two things: # 1) authenticates enrollment requests which contain a username and password # (also known as an enrollment ID and secret). # 2) once authenticated, retrieves the identity's attribute names and # values which the fabric-ca-server optionally puts into TCerts # which it issues for transacting on the Hyperledger Fabric blockchain. # These attributes are useful for making access control decisions in # chaincode. # There are two main configuration options: # 1) The fabric-ca-server is the registry. # This is true if "ldap.enabled" in the ldap section below is false. # 2) An LDAP server is the registry, in which case the fabric-ca-server # calls the LDAP server to perform these tasks. # This is true if "ldap.enabled" in the ldap section below is true, # which means this "registry" section is ignored. ############################################################################# registry: # Maximum number of times a password/secret can be reused for enrollment # (default: -1, which means there is no limit) maxenrollments: -1 # Contains identity information which is used when LDAP is disabled identities: - name: admin pass: adminpw type: client affiliation: "" attrs: hf.Registrar.Roles: "*" hf.Registrar.DelegateRoles: "*" hf.Revoker: true hf.IntermediateCA: true hf.GenCRL: true hf.Registrar.Attributes: "*" hf.AffiliationMgr: true ############################################################################# # Database section # Supported types are: "sqlite3", "postgres", and "mysql". # The datasource value depends on the type. # If the type is "sqlite3", the datasource value is a file name to use # as the database store. Since "sqlite3" is an embedded database, it # may not be used if you want to run the fabric-ca-server in a cluster. # To run the fabric-ca-server in a cluster, you must choose "postgres" # or "mysql". ############################################################################# db: type: sqlite3 datasource: fabric-ca-server.db tls: enabled: false certfiles: client: certfile: keyfile: ############################################################################# # LDAP section # If LDAP is enabled, the fabric-ca-server calls LDAP to: # 1) authenticate enrollment ID and secret (i.e. username and password) # for enrollment requests; # 2) To retrieve identity attributes ############################################################################# ldap: # Enables or disables the LDAP client (default: false) # If this is set to true, the "registry" section is ignored. enabled: false # The URL of the LDAP server url: ldap://:@:/ # TLS configuration for the client connection to the LDAP server tls: certfiles: client: certfile: keyfile: # Attribute related configuration for mapping from LDAP entries to Fabric CA attributes attribute: # 'names' is an array of strings containing the LDAP attribute names which are # requested from the LDAP server for an LDAP identity's entry names: ['uid','member'] # The 'converters' section is used to convert an LDAP entry to the value of # a fabric CA attribute. # 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 boolean expression # evaluates to true). # converters: # - name: hf.Revoker # value: attr("uid") =~ "revoker*" converters: - name: value: # The 'maps' section contains named maps which may be referenced by the 'map' # function in the 'converters' section to map LDAP responses to arbitrary values. # For example, assume a user has an LDAP attribute named 'member' which has multiple # values which are each a distinguished name (i.e. a DN). For simplicity, assume the # values of the 'member' attribute are 'dn1', 'dn2', and 'dn3'. # Further assume the following configuration. # converters: # - name: hf.Registrar.Roles # value: map(attr("member"),"groups") # maps: # groups: # - name: dn1 # value: peer # - name: dn2 # value: client # The value of the user's 'hf.Registrar.Roles' attribute is then computed to be # "peer,client,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 "peer" and "dn2" with "client". maps: groups: - name: value: ############################################################################# # Affiliations section. Fabric CA server can be bootstrapped with the # affiliations specified in this section. Affiliations are specified as maps. # For example: # businessunit1: # department1: # - team1 # businessunit2: # - department2 # - department3 # # Affiliations are hierarchical in nature. In the above example, # department1 (used as businessunit1.department1) is the child of businessunit1. # team1 (used as businessunit1.department1.team1) is the child of department1. # department2 (used as businessunit2.department2) and department3 (businessunit2.department3) # are children of businessunit2. # Note: Affiliations are case sensitive except for the non-leaf affiliations # (like businessunit1, department1, businessunit2) that are specified in the configuration file, # which are always stored in lower case. ############################################################################# affiliations: org1: - department1 - department2 org2: - department1 org3: - department1 ############################################################################# # Signing section # # The "default" subsection is used to sign enrollment certificates; # the default expiration ("expiry" field) is "8760h", which is 1 year in hours. # # The "ca" profile subsection is used to sign intermediate CA certificates; # the default expiration ("expiry" field) is "43800h" which is 5 years in hours. # Note that "isca" is true, meaning that it issues a CA certificate. # A maxpathlen of 0 means that the intermediate CA cannot issue other # intermediate CA certificates, though it can still issue end entity certificates. # (See RFC 5280, section 4.2.1.9) # # The "tls" profile subsection is used to sign TLS certificate requests; # the default expiration ("expiry" field) is "8760h", which is 1 year in hours. ############################################################################# signing: default: usage: - digital signature expiry: 8760h profiles: ca: usage: - cert sign - crl sign expiry: 43800h caconstraint: isca: true maxpathlen: 0 tls: usage: - signing - key encipherment - server auth - client auth - key agreement expiry: 8760h ########################################################################### # Certificate Signing Request (CSR) section. # This controls the creation of the root CA certificate. # The expiration for the root CA certificate is configured with the # "ca.expiry" field below, whose default value is "131400h" which is # 15 years in hours. # The pathlength field is used to limit CA certificate hierarchy as described # in section 4.2.1.9 of RFC 5280. # Examples: # 1) No pathlength value means no limit is requested. # 2) pathlength == 1 means a limit of 1 is requested which is the default for # a root CA. This means the root CA can issue intermediate CA certificates, # but these intermediate CAs may not in turn issue other CA certificates # though they can still issue end entity certificates. # 3) pathlength == 0 means a limit of 0 is requested; # this is the default for an intermediate CA, which means it can not issue # CA certificates though it can still issue end entity certificates. ########################################################################### csr: cn: ca-org2 names: - C: US ST: "New York" L: "New York" O: ca-org2 OU: ca-org2 hosts: - localhost - example.com - ca-org2 ca: expiry: 131400h pathlength: 1 ############################################################################# # BCCSP (BlockChain Crypto Service Provider) section is used to select which # crypto library implementation to use ############################################################################# bccsp: default: SW sw: hash: SHA2 security: 256 filekeystore: # The directory used for the software file-based keystore keystore: msp/keystore ############################################################################# # Multi CA section # # Each Fabric CA server contains one CA by default. This section is used # to configure multiple CAs in a single server. # # 1) --cacount # Automatically generate non-default CAs. The names of these # additional CAs are "ca1", "ca2", ... "caN", where "N" is # This is particularly useful in a development environment to quickly set up # multiple CAs. Note that, this config option is not applicable to intermediate CA server # i.e., Fabric CA server that is started with intermediate.parentserver.url config # option (-u command line option) # # 2) --cafiles # For each CA config file in the list, generate a separate signing CA. Each CA # config file in this list MAY contain all of the same elements as are found in # the server config file except port, debug, and tls sections. # # Examples: # fabric-ca-server start -b admin:adminpw --cacount 2 # # fabric-ca-server start -b admin:adminpw --cafiles ca/ca1/fabric-ca-server-config.yaml # --cafiles ca/ca2/fabric-ca-server-config.yaml # ############################################################################# cacount: cafiles: ############################################################################# # Intermediate CA section # # The relationship between servers and CAs is as follows: # 1) A single server process may contain or function as one or more CAs. # This is configured by the "Multi CA section" above. # 2) Each CA is either a root CA or an intermediate CA. # 3) Each intermediate CA has a parent CA which is either a root CA or another intermediate CA. # # This section pertains to configuration of #2 and #3. # If the "intermediate.parentserver.url" property is set, # then this is an intermediate CA with the specified parent # CA. # # parentserver section # url - The URL of the parent server # caname - Name of the CA to enroll within the server # # enrollment section used to enroll intermediate CA with parent CA # profile - Name of the signing profile to use in issuing the certificate # label - Label to use in HSM operations # # tls section for secure socket connection # certfiles - PEM-encoded list of trusted root certificate files # client: # certfile - PEM-encoded certificate file for when client authentication # is enabled on server # keyfile - PEM-encoded key file for when client authentication # is enabled on server ############################################################################# intermediate: parentserver: url: caname: enrollment: hosts: profile: label: tls: certfiles: client: certfile: keyfile:

تنظیمات Csr و نام CA با پیکربندی CA Org1 متفاوت است. تنظیمات دیگر مانند ca org1 هستند.

csr: cn: ca-org2 names: - C: US ST: "New York" L: "New York" O: ca-org2 OU: ca-org2 hosts: - localhost - example.com - ca-org2

ca-org2 نام سرویس فابریک سرور ca در kubernetes است.

ca: # Name of this CA name: Org2CA

فایل پیکربندی Fabric CA که در پروژه برای Org3 تعریف شده است به شرح زیر است فایل پیکربندی در پوشه deploy/k8s/fabricfiles/organizations/fabric-ca/org3 قرار دارد.

############################################################################# # This is a configuration file for the fabric-ca-server command. # # COMMAND LINE ARGUMENTS AND ENVIRONMENT VARIABLES # ------------------------------------------------ # Each configuration element can be overridden via command line # arguments or environment variables. The precedence for determining # the value of each element is as follows: # 1) command line argument # Examples: # a) --port 443 # To set the listening port # b) --ca.keyfile ../mykey.pem # To set the "keyfile" element in the "ca" section below; # note the '.' separator character. # 2) environment variable # Examples: # a) FABRIC_CA_SERVER_PORT=443 # To set the listening port # b) FABRIC_CA_SERVER_CA_KEYFILE="../mykey.pem" # To set the "keyfile" element in the "ca" section below; # note the '_' separator character. # 3) configuration file # 4) default value (if there is one) # All default values are shown beside each element below. # # FILE NAME ELEMENTS # ------------------ # The value of all fields whose name ends with "file" or "files" are # name or names of other files. # For example, see "tls.certfile" and "tls.clientauth.certfiles". # The value of each of these fields can be a simple filename, a # relative path, or an absolute path. If the value is not an # absolute path, it is interpretted as being relative to the location # of this configuration file. # ############################################################################# # Version of config file version: 1.2.0 # Server's listening port (default: 7054) port: 7054 # Enables debug logging (default: false) debug: false # Size limit of an acceptable CRL in bytes (default: 512000) crlsizelimit: 512000 ############################################################################# # TLS section for the server's listening port # # The following types are supported for client authentication: NoClientCert, # RequestClientCert, RequireAnyClientCert, VerifyClientCertIfGiven, # and RequireAndVerifyClientCert. # # Certfiles is a list of root certificate authorities that the server uses # when verifying client certificates. ############################################################################# tls: # Enable TLS (default: false) enabled: true # TLS for the server's listening port certfile: keyfile: clientauth: type: noclientcert certfiles: ############################################################################# # The CA section contains information related to the Certificate Authority # including the name of the CA, which should be unique for all members # of a blockchain network. It also includes the key and certificate files # used when issuing enrollment certificates (ECerts) and transaction # certificates (TCerts). # The chainfile (if it exists) contains the certificate chain which # should be trusted for this CA, where the 1st in the chain is always the # root CA certificate. ############################################################################# ca: # Name of this CA name: Org3CA # Key file (is only used to import a private key into BCCSP) keyfile: # Certificate file (default: ca-cert.pem) certfile: # Chain file chainfile: ############################################################################# # The gencrl REST endpoint is used to generate a CRL that contains revoked # certificates. This section contains configuration options that are used # during gencrl request processing. ############################################################################# crl: # Specifies expiration for the generated CRL. The number of hours # specified by this property is added to the UTC time, the resulting time # is used to set the 'Next Update' date of the CRL. expiry: 24h ############################################################################# # The registry section controls how the fabric-ca-server does two things: # 1) authenticates enrollment requests which contain a username and password # (also known as an enrollment ID and secret). # 2) once authenticated, retrieves the identity's attribute names and # values which the fabric-ca-server optionally puts into TCerts # which it issues for transacting on the Hyperledger Fabric blockchain. # These attributes are useful for making access control decisions in # chaincode. # There are two main configuration options: # 1) The fabric-ca-server is the registry. # This is true if "ldap.enabled" in the ldap section below is false. # 2) An LDAP server is the registry, in which case the fabric-ca-server # calls the LDAP server to perform these tasks. # This is true if "ldap.enabled" in the ldap section below is true, # which means this "registry" section is ignored. ############################################################################# registry: # Maximum number of times a password/secret can be reused for enrollment # (default: -1, which means there is no limit) maxenrollments: -1 # Contains identity information which is used when LDAP is disabled identities: - name: admin pass: adminpw type: client affiliation: "" attrs: hf.Registrar.Roles: "*" hf.Registrar.DelegateRoles: "*" hf.Revoker: true hf.IntermediateCA: true hf.GenCRL: true hf.Registrar.Attributes: "*" hf.AffiliationMgr: true ############################################################################# # Database section # Supported types are: "sqlite3", "postgres", and "mysql". # The datasource value depends on the type. # If the type is "sqlite3", the datasource value is a file name to use # as the database store. Since "sqlite3" is an embedded database, it # may not be used if you want to run the fabric-ca-server in a cluster. # To run the fabric-ca-server in a cluster, you must choose "postgres" # or "mysql". ############################################################################# db: type: sqlite3 datasource: fabric-ca-server.db tls: enabled: false certfiles: client: certfile: keyfile: ############################################################################# # LDAP section # If LDAP is enabled, the fabric-ca-server calls LDAP to: # 1) authenticate enrollment ID and secret (i.e. username and password) # for enrollment requests; # 2) To retrieve identity attributes ############################################################################# ldap: # Enables or disables the LDAP client (default: false) # If this is set to true, the "registry" section is ignored. enabled: false # The URL of the LDAP server url: ldap://:@:/ # TLS configuration for the client connection to the LDAP server tls: certfiles: client: certfile: keyfile: # Attribute related configuration for mapping from LDAP entries to Fabric CA attributes attribute: # 'names' is an array of strings containing the LDAP attribute names which are # requested from the LDAP server for an LDAP identity's entry names: ['uid','member'] # The 'converters' section is used to convert an LDAP entry to the value of # a fabric CA attribute. # 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 boolean expression # evaluates to true). # converters: # - name: hf.Revoker # value: attr("uid") =~ "revoker*" converters: - name: value: # The 'maps' section contains named maps which may be referenced by the 'map' # function in the 'converters' section to map LDAP responses to arbitrary values. # For example, assume a user has an LDAP attribute named 'member' which has multiple # values which are each a distinguished name (i.e. a DN). For simplicity, assume the # values of the 'member' attribute are 'dn1', 'dn2', and 'dn3'. # Further assume the following configuration. # converters: # - name: hf.Registrar.Roles # value: map(attr("member"),"groups") # maps: # groups: # - name: dn1 # value: peer # - name: dn2 # value: client # The value of the user's 'hf.Registrar.Roles' attribute is then computed to be # "peer,client,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 "peer" and "dn2" with "client". maps: groups: - name: value: ############################################################################# # Affiliations section. Fabric CA server can be bootstrapped with the # affiliations specified in this section. Affiliations are specified as maps. # For example: # businessunit1: # department1: # - team1 # businessunit2: # - department2 # - department3 # # Affiliations are hierarchical in nature. In the above example, # department1 (used as businessunit1.department1) is the child of businessunit1. # team1 (used as businessunit1.department1.team1) is the child of department1. # department2 (used as businessunit2.department2) and department3 (businessunit2.department3) # are children of businessunit2. # Note: Affiliations are case sensitive except for the non-leaf affiliations # (like businessunit1, department1, businessunit2) that are specified in the configuration file, # which are always stored in lower case. ############################################################################# affiliations: org1: - department1 - department2 org2: - department1 org3: - department1 ############################################################################# # Signing section # # The "default" subsection is used to sign enrollment certificates; # the default expiration ("expiry" field) is "8760h", which is 1 year in hours. # # The "ca" profile subsection is used to sign intermediate CA certificates; # the default expiration ("expiry" field) is "43800h" which is 5 years in hours. # Note that "isca" is true, meaning that it issues a CA certificate. # A maxpathlen of 0 means that the intermediate CA cannot issue other # intermediate CA certificates, though it can still issue end entity certificates. # (See RFC 5280, section 4.2.1.9) # # The "tls" profile subsection is used to sign TLS certificate requests; # the default expiration ("expiry" field) is "8760h", which is 1 year in hours. ############################################################################# signing: default: usage: - digital signature expiry: 8760h profiles: ca: usage: - cert sign - crl sign expiry: 43800h caconstraint: isca: true maxpathlen: 0 tls: usage: - signing - key encipherment - server auth - client auth - key agreement expiry: 8760h ########################################################################### # Certificate Signing Request (CSR) section. # This controls the creation of the root CA certificate. # The expiration for the root CA certificate is configured with the # "ca.expiry" field below, whose default value is "131400h" which is # 15 years in hours. # The pathlength field is used to limit CA certificate hierarchy as described # in section 4.2.1.9 of RFC 5280. # Examples: # 1) No pathlength value means no limit is requested. # 2) pathlength == 1 means a limit of 1 is requested which is the default for # a root CA. This means the root CA can issue intermediate CA certificates, # but these intermediate CAs may not in turn issue other CA certificates # though they can still issue end entity certificates. # 3) pathlength == 0 means a limit of 0 is requested; # this is the default for an intermediate CA, which means it can not issue # CA certificates though it can still issue end entity certificates. ########################################################################### csr: cn: ca-org3 names: - C: US ST: "New York" L: "New York" O: ca-org3 OU: ca-org3 hosts: - localhost - example.com - ca-org3 ca: expiry: 131400h pathlength: 1 ############################################################################# # BCCSP (BlockChain Crypto Service Provider) section is used to select which # crypto library implementation to use ############################################################################# bccsp: default: SW sw: hash: SHA2 security: 256 filekeystore: # The directory used for the software file-based keystore keystore: msp/keystore ############################################################################# # Multi CA section # # Each Fabric CA server contains one CA by default. This section is used # to configure multiple CAs in a single server. # # 1) --cacount # Automatically generate non-default CAs. The names of these # additional CAs are "ca1", "ca2", ... "caN", where "N" is # This is particularly useful in a development environment to quickly set up # multiple CAs. Note that, this config option is not applicable to intermediate CA server # i.e., Fabric CA server that is started with intermediate.parentserver.url config # option (-u command line option) # # 2) --cafiles # For each CA config file in the list, generate a separate signing CA. Each CA # config file in this list MAY contain all of the same elements as are found in # the server config file except port, debug, and tls sections. # # Examples: # fabric-ca-server start -b admin:adminpw --cacount 2 # # fabric-ca-server start -b admin:adminpw --cafiles ca/ca1/fabric-ca-server-config.yaml # --cafiles ca/ca2/fabric-ca-server-config.yaml # ############################################################################# cacount: cafiles: ############################################################################# # Intermediate CA section # # The relationship between servers and CAs is as follows: # 1) A single server process may contain or function as one or more CAs. # This is configured by the "Multi CA section" above. # 2) Each CA is either a root CA or an intermediate CA. # 3) Each intermediate CA has a parent CA which is either a root CA or another intermediate CA. # # This section pertains to configuration of #2 and #3. # If the "intermediate.parentserver.url" property is set, # then this is an intermediate CA with the specified parent # CA. # # parentserver section # url - The URL of the parent server # caname - Name of the CA to enroll within the server # # enrollment section used to enroll intermediate CA with parent CA # profile - Name of the signing profile to use in issuing the certificate # label - Label to use in HSM operations # # tls section for secure socket connection # certfiles - PEM-encoded list of trusted root certificate files # client: # certfile - PEM-encoded certificate file for when client authentication # is enabled on server # keyfile - PEM-encoded key file for when client authentication # is enabled on server ############################################################################# intermediate: parentserver: url: caname: enrollment: hosts: profile: label: tls: certfiles: client: certfile: keyfile:

تنظیمات Csr و نام CA با پیکربندی CA Org1 متفاوت است. تنظیمات دیگر مانند ca org1 هستند.

csr: cn: ca-org3 names: - C: US ST: "New York" L: "New York" O: ca-org3 OU: ca-org3 hosts: - localhost - example.com - ca-org3

ca-org3 نام سرویس فابریک سرور ca در kubernetes است.

ca: # Name of this CA name: Org3CA

پس از تنظیم تنظیمات Fabric CA Server برای Orderer، Org1، Org2 و Org3، می‌توانیم سرورهای CA را در kubernetes مستقر کنیم.

نصب سرور Fabric CA در Kubernetes

آموزش نحوه ادغام Hyperledger Fabric با Spring Boot

بیایید برای دسترسی به فایل‌های فابریک از pod، fabricfiles-pv.yaml و fabricfiles-pvc.yaml، ادعای حجم پایدار و ماندگاری ایجاد کنیم.

فایل fabricfiles-pv.yaml در پوشه deploy/k8s/pv قرار دارد.

فایل fabricfiles-pvc.yaml در پوشه deploy/k8s/pvc قرار دارد.

apiVersion: v1 kind: PersistentVolume metadata: name: fabricfiles-pv labels: name: fabricfiles spec: storageClassName: default capacity: storage: 5Gi volumeMode: Filesystem accessModes: - ReadWriteOnce nfs: path: /srv/kubedata/fabricfiles server: 192.168.12.9
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: fabricfiles-pvc spec: storageClassName: default accessModes: - ReadWriteOnce resources: requests: storage: 4050Mi selector: matchLabels: name: fabricfiles
nfs: path: /srv/kubedata/fabricfiles server: 192.168.12.9

192.168.12.9 آی پی سرور nfs است.

/srv/kubedata/fabricfiles دایرکتوری است که فایل های فابریک در سرور nfs در آن قرار دارند.

اجازه می دهد تا یک سرویس و استقرار سرور Fabric Orderer CA ایجاد کنیم، ca-orderer.yaml و ca-orderer-svc.yaml. فایل های yaml در پوشه deploy/k8s/ca هستند.

apiVersion: v1 kind: Service metadata: name: ca-orderer labels: app: ca-orderer spec: type: ClusterIP selector: app: ca-orderer ports: - protocol: TCP targetPort: 10054 port: 10054
apiVersion: apps/v1 kind: Deployment metadata: name: ca-orderer labels: app: ca-orderer spec: selector: matchLabels: app: ca-orderer replicas: 1 template: metadata: labels: app: ca-orderer spec: containers: - name: ca-orderer image: hyperledger/fabric-ca:1.4.9 imagePullPolicy: IfNotPresent command: [ "fabric-ca-server", "start", "-b", "admin:adminpw", "--port", "10054", "-d" ] resources: requests: memory: "300Mi" cpu: "300m" limits: memory: "500Mi" cpu: "350m" ports: - containerPort: 10054 env: - name: FABRIC_CA_SERVER_CA_NAME value: ca-orderer - name: FABRIC_CA_SERVER_TLS_ENABLED value: "true" volumeMounts: - name: data mountPath: /etc/hyperledger/fabric-ca-server subPath: organizations/fabric-ca/ordererOrg volumes: - name: data persistentVolumeClaim: claimName: fabricfiles-pvc
kind: Service metadata: name: ca-orderer

ca-orderer نام سرویس kubernetes سرور Orderer Fabric CA است. باید در پیکربندی میزبان csr در فایل پیکربندی Fabric CA اضافه شود.

ports: - protocol: TCP targetPort: 10054 port: 10054

targetPort پورت داخلی کانتینر است. 10054

پورت پورت سرویس است. 10054

"fabric-ca-server", "start", "-b", "admin:adminpw", "--port", "10054", "-d"

هنگامی که LDAP غیرفعال است، گزینه -b (هویت بوت استرپ) برای مقداردهی اولیه مورد نیاز است. حداقل یک هویت بوت استرپ برای راه اندازی سرور Fabric CA مورد نیاز است. این هویت مدیر سرور است.

admin:adminpw

اطلاعات مدیریت سرور نام کاربری ادمین admin و رمز عبور adminpw است.

--port", "10054"

10054 به عنوان پورت کانتینر سرور ca اختصاص داده شده است.

env: - name: FABRIC_CA_SERVER_CA_NAME value: ca-orderer - name: FABRIC_CA_SERVER_TLS_ENABLED value: "true"

Tls aws فعال است و ca-name ca-orderer اختصاص داده شده است.

volumeMounts: - name: data mountPath: /etc/hyperledger/fabric-ca-server subPath: organizations/fabric-ca/ordererOrg

Organizations/fabric-ca/ordererOrg: مسیر فایل پیکربندی سرور ca در فایل های فابریک

اجازه می دهد تا یک سرویس و استقرار سرور Fabric CA Org1 ایجاد کنیم، ca-org1.yaml و ca-org1-svc.yaml. فایل های yaml در پوشه deploy/k8s/ca هستند.

apiVersion: v1 kind: Service metadata: name: ca-org1 labels: app: ca-org1 spec: type: ClusterIP selector: app: ca-org1 # deploymenti bu selector üzerinden bulur.deploymentdeki matchLabels ile aynı olmalı. ports: - protocol: TCP targetPort: 7054 # contanier portu port: 7054 # service portu
apiVersion: apps/v1 kind: Deployment metadata: name: ca-org1 labels: app: ca-org1 spec: selector: matchLabels: app: ca-org1 replicas: 1 template: metadata: labels: app: ca-org1 spec: containers: - name: ca-org1 image: hyperledger/fabric-ca:1.4.9 imagePullPolicy: IfNotPresent command: [ "fabric-ca-server", "start", "-b", "admin:adminpw", "--port", "7054", "-d" ] resources: requests: memory: "300Mi" cpu: "250m" limits: memory: "500Mi" cpu: "350m" ports: - containerPort: 7054 env: - name: FABRIC_CA_SERVER_CA_NAME value: ca-org1 - name: FABRIC_CA_SERVER_TLS_ENABLED value: "true" - name: FABRIC_CA_SERVER_CSR_CN value: "ca-org1" - name: FABRIC_CA_SERVER_CSR_HOSTS value: "ca-org1" volumeMounts: - name: data mountPath: /etc/hyperledger/fabric-ca-server subPath: organizations/fabric-ca/org1 volumes: - name: data persistentVolumeClaim: claimName: fabricfiles-pvc
kind: Service metadata: name: ca-org1

ca-org1 نام سرویس kubernetes سرور Org1 Fabric CA است. باید در پیکربندی میزبان csr در فایل پیکربندی Fabric CA اضافه شود.

ports: - protocol: TCP targetPort: 7054 port: 7054

targetPort پورت داخلی کانتینر است.7054

پورت سرویس port.7054 است

--port", "7054"

7054 به عنوان پورت کانتینر سرور ca اختصاص داده شده است.

- name: FABRIC_CA_SERVER_CA_NAME value: ca-org1 - name: FABRIC_CA_SERVER_TLS_ENABLED value: "true" - name: FABRIC_CA_SERVER_CSR_CN value: "ca-org1" - name: FABRIC_CA_SERVER_CSR_HOSTS value: "ca-org1"

Tls فعال شد، نام ca ca-org1 اختصاص یافت و میزبان csr و cn ca-org1 اختصاص یافت.

volumeMounts: - name: data mountPath: /etc/hyperledger/fabric-ca-server subPath: organizations/fabric-ca/org1

Organizations/fabric-ca/org1: مسیر فایل پیکربندی سرور ca در فایل های فابریک

اجازه می دهد تا یک سرویس و استقرار سرور Fabric CA Org2 ایجاد کنیم، ca-org2.yaml و ca-org2-svc.yaml. فایل های yaml در پوشه deploy/k8s/ca هستند.

apiVersion: v1 kind: Service metadata: name: ca-org2 labels: app: ca-org2 spec: type: ClusterIP selector: app: ca-org2 ports: - protocol: TCP targetPort: 8054 port: 8054
apiVersion: apps/v1 kind: Deployment metadata: name: ca-org2 labels: app: ca-org2 spec: selector: matchLabels: app: ca-org2 replicas: 1 template: metadata: labels: app: ca-org2 spec: containers: - name: ca-org2 image: hyperledger/fabric-ca:1.4.9 imagePullPolicy: IfNotPresent command: [ "fabric-ca-server", "start", "-b", "admin:adminpw", "--port", "8054", "-d" ] resources: requests: memory: "300Mi" cpu: "300m" limits: memory: "500Mi" cpu: "350m" ports: - containerPort: 8054 env: - name: FABRIC_CA_SERVER_CA_NAME value: ca-org2 - name: FABRIC_CA_SERVER_TLS_ENABLED value: "true" - name: FABRIC_CA_SERVER_CSR_CN value: "ca-org2" - name: FABRIC_CA_SERVER_CSR_HOSTS value: "ca-org2" volumeMounts: - name: data mountPath: /etc/hyperledger/fabric-ca-server subPath: organizations/fabric-ca/org2 volumes: - name: data persistentVolumeClaim: claimName: fabricfiles-pvc
kind: Service metadata: name: ca-org2

ca-org2 نام سرویس kubernetes سرور Org2 Fabric CA است. باید در پیکربندی میزبان csr در فایل پیکربندی Fabric CA اضافه شود.

ports: - protocol: TCP targetPort: 8054 port: 8054

targetPort پورت داخلی کانتینر است.8054

پورت همان پورت سرویس است.8054

--port", "8054"

8054 به عنوان پورت کانتینر سرور ca اختصاص داده شده است.

- name: FABRIC_CA_SERVER_CA_NAME value: ca-org2 - name: FABRIC_CA_SERVER_TLS_ENABLED value: "true" - name: FABRIC_CA_SERVER_CSR_CN value: "ca-org2" - name: FABRIC_CA_SERVER_CSR_HOSTS value: "ca-org2"

Tls فعال شد، نام ca ca-org2 اختصاص یافت و csr میزبان و cn ca-org2 اختصاص یافت.

olumeMounts: - name: data mountPath: /etc/hyperledger/fabric-ca-server subPath: organizations/fabric-ca/org2

Organizations/fabric-ca/org2: مسیر فایل پیکربندی سرور ca در فایل های فابریک

اجازه می دهد تا یک سرویس و استقرار سرور Fabric CA Org3 ایجاد کنیم، ca-org3.yaml و ca-org3-svc.yaml. فایل های yaml در پوشه deploy/k8s/ca هستند.

apiVersion: v1 kind: Service metadata: name: ca-org3 labels: app: ca-org3 spec: type: ClusterIP selector: app: ca-org3 # deploymenti bu selector üzerinden bulur.deploymentdeki matchLabels ile aynı olmalı. ports: - protocol: TCP targetPort: 9054 port: 9054
apiVersion: apps/v1 kind: Deployment metadata: name: ca-org3 labels: app: ca-org3 spec: selector: matchLabels: app: ca-org3 replicas: 1 template: metadata: labels: app: ca-org3 spec: containers: - name: ca-org3 image: hyperledger/fabric-ca:1.4.9 imagePullPolicy: IfNotPresent command: [ "fabric-ca-server", "start", "-b", "admin:adminpw", "--port", "9054", "-d" ] resources: requests: memory: "300Mi" cpu: "300m" limits: memory: "500Mi" cpu: "350m" ports: - containerPort: 9054 env: - name: FABRIC_CA_SERVER_CA_NAME value: ca-org3 - name: FABRIC_CA_SERVER_TLS_ENABLED value: "true" - name: FABRIC_CA_SERVER_CSR_CN value: "ca-org3" - name: FABRIC_CA_SERVER_CSR_HOSTS value: "ca-org3" volumeMounts: - name: data mountPath: /etc/hyperledger/fabric-ca-server subPath: organizations/fabric-ca/org3 volumes: - name: data persistentVolumeClaim: claimName: fabricfiles-pvc
kind: Service metadata: name: ca-org3

ca-org3 نام سرویس kubernetes سرور Org3 Fabric CA است. باید در پیکربندی میزبان csr در فایل پیکربندی Fabric CA اضافه شود.

ports: - protocol: TCP targetPort: 9054 port: 9054

targetPort پورت داخلی کانتینر است.9054

پورت همان پورت سرویس است.9054

--port", "9054"

9054 به عنوان پورت کانتینر سرور ca اختصاص داده شده است.

- name: FABRIC_CA_SERVER_CA_NAME value: ca-org3 - name: FABRIC_CA_SERVER_TLS_ENABLED value: "true" - name: FABRIC_CA_SERVER_CSR_CN value: "ca-org3" - name: FABRIC_CA_SERVER_CSR_HOSTS value: "ca-org3"

Tls فعال شد، ca نام ca-org3 اختصاص داده شد و csr host و cn ca-org3 اختصاص داده شد.

volumeMounts: - name: data mountPath: /etc/hyperledger/fabric-ca-server subPath: organizations/fabric-ca/org3

Organizations/fabric-ca/org3: مسیر فایل پیکربندی سرور ca در فایل های فابریک

بیایید شغلی را تعریف کنیم که گواهی‌های سفارش دهنده، org1، org2 و org3 را ایجاد کند.

بیایید با دستور Vagrant ssh به ماشین مجازی kubernetes master node متصل شویم.

$ vagrant ssh k8smaster

بیایید به دایرکتوری برویم که اسکریپت های نصب kubernetes در آن قرار دارند. این دایرکتوری همان پوشه deploy/k8s در پروژه است. با Vagrant، این دایرکتوری با ماشین مجازی همگام سازی می شود.

$ cd /vagrant/k8s

گسترش حجم پایدار برای فایل های فابریک

$ kubectl apply -f pv/fabricfiles-pv.yaml

آموزش سری مقالات ادغام Hyperledger Fabric با Spring Boot

استقرار ادعای حجم پایدار برای فایل‌های فابریک

$ kubectl apply -f pvc/fabricfiles-pvc.yaml

سری مقالات ادغام Hyperledger Fabric با Spring Boot

استقرار سرور فابریک ca

$ kubectl apply -f ca/

ادغام Hyperledger Fabric با Spring Boot از سری مقالات آموزشی

ایجاد سرور Fabric ca در انتظار تکمیل است

$ kubectl wait --for condition=available --timeout=300s deployment -l "app in (ca-orderer,ca-org1,ca-org2,ca-org3)"

آموزش چکونگی ادغام Hyperledger Fabric با Spring Boot

در نهایت، بیایید بررسی کنیم که آیا غلاف های ما از ایده لنز در حال اجرا هستند یا خیر.

چگونگی ادغام Hyperledger Fabric با Spring Boot

همه غلاف های فابریک سرور ca در حال اجرا هستند.

به طور کلی، معرفی Fabric CA Server و نصب Fabric CA Server در Kubernetes توضیح داده شد.

مدیر سایت

مدیر سایت

دیدگاه‌ خود را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

آرتا رسانه
آرتا رسانه
دیجیتال مارکتینگ چیست؟
Loading
/
Youtube Instagram Linkedin
پیمایش به بالا