Date   

Re: Alternative of cryptogen for Prod

Abhijeet Bhowmik <abhijeet@...>
 

Hey,

Thanks to all for the help. I am extremely grateful to everyone.

Abhijeet Bhowmik

On Mon, Nov 4, 2019 at 9:51 PM Joe Alewine <joe.alewine@...> wrote:
Abhijeet,
 
Certificate Authorities --- specifically, the Fabric CA --- should be used to create all of the certificates in a production scenario (it is a best practice tp stand up one CA for each organization and the organization's related identities, MSP, and nodes).
 
Consult the Fabric CA User's Guide for more information: https://hyperledger-fabric-ca.readthedocs.io/en/latest/
 
Regards,
 
Joe Alewine
IBM Blockchain, Raleigh
 
rocket chat: joe-alewine
slack: joe.alewine
 
 
 
----- Original message -----
From: "Nye Liu" <nye@...>
Sent by: fabric@...
To: fabric@...
Cc:
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Alternative of cryptogen for Prod
Date: Sun, Nov 3, 2019 7:43 AM
 

It is described in the Operations Guide.

On 11/3/2019 1:11 AM, Abhijeet Bhowmik wrote:
Hey,
 
Just to be specific, I was referring to the certificates that we set up at peers and place public keys at orderer. From where do we obtain that folder structure (MSP and TLS)?
 
Thanks and Regards
Abhijeet Bhowmik
 
On Sun, Nov 3, 2019 at 10:44 AM Mrudav Shukla <mrudavshukla@...> wrote:
Hi Abhijeet,
 
For prod, you’ll need to generate certs from CAs. References:
Cheers,
Mrudav 
 
On Sun, 3 Nov 2019 at 10:22 AM, Abhijeet Bhowmik <abhijeet@...> wrote:
Greetings Everyone,
 
I am dwelling in the answer of the question: "If not cryptogen in Prod, then what and how?".
Right now, generating org certificates is a pretty straightforward task while getting started with HLF. But after reading the docs, the question has been thrown upon me that how can we configure certificates in Prod. I know it's a naive question to ask but being a beginner and stepping my first foot into actually hosting fabric application, I am obliged to ask the community to help me out.
 
 
Thanks and Regards
Abhijeet Bhowmik
 


Re: solo to kafka

Artem Barger <bartem@...>
 

Migration from solo to kafka is not supported. Solo orderer should be used for development and testing only.
 

----- Original message -----
From: "Battaglia TLC" <antonio@...>
Sent by: fabric@...
To: fabric@...
Cc:
Subject: [EXTERNAL] [Hyperledger Fabric] solo to kafka
Date: Mon, Nov 4, 2019 8:45 PM
 
Hello everybody,

i want change orderer from solo to raft. I can switch off the network
but i want to mantain data in the ledger after restart with new orderer.

It's possible? I haven't found documentation.

Best regards.

Antonio




 
 


solo to kafka

Battaglia TLC
 

Hello everybody,

i want change orderer from solo to raft. I can switch off the network but i want to mantain data in the ledger after restart with new orderer.

It's possible? I haven't found documentation.

Best regards.

Antonio


Re: Alternative of cryptogen for Prod

Joe Alewine <joe.alewine@...>
 

Abhijeet,
 
Certificate Authorities --- specifically, the Fabric CA --- should be used to create all of the certificates in a production scenario (it is a best practice tp stand up one CA for each organization and the organization's related identities, MSP, and nodes).
 
Consult the Fabric CA User's Guide for more information: https://hyperledger-fabric-ca.readthedocs.io/en/latest/
 
Regards,
 
Joe Alewine
IBM Blockchain, Raleigh
 
rocket chat: joe-alewine
slack: joe.alewine
 
 
 

----- Original message -----
From: "Nye Liu" <nye@...>
Sent by: fabric@...
To: fabric@...
Cc:
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Alternative of cryptogen for Prod
Date: Sun, Nov 3, 2019 7:43 AM
 

It is described in the Operations Guide.

On 11/3/2019 1:11 AM, Abhijeet Bhowmik wrote:
Hey,
 
Just to be specific, I was referring to the certificates that we set up at peers and place public keys at orderer. From where do we obtain that folder structure (MSP and TLS)?
 
Thanks and Regards
Abhijeet Bhowmik
 
On Sun, Nov 3, 2019 at 10:44 AM Mrudav Shukla <mrudavshukla@...> wrote:
Hi Abhijeet,
 
For prod, you’ll need to generate certs from CAs. References:
Cheers,
Mrudav 
 
On Sun, 3 Nov 2019 at 10:22 AM, Abhijeet Bhowmik <abhijeet@...> wrote:
Greetings Everyone,
 
I am dwelling in the answer of the question: "If not cryptogen in Prod, then what and how?".
Right now, generating org certificates is a pretty straightforward task while getting started with HLF. But after reading the docs, the question has been thrown upon me that how can we configure certificates in Prod. I know it's a naive question to ask but being a beginner and stepping my first foot into actually hosting fabric application, I am obliged to ask the community to help me out.
 
 
Thanks and Regards
Abhijeet Bhowmik
 


Re: Channel Registration Failed

White, Spencer (S.)
 

Hi,

I believe I resolved the issue. Within my chaincode folder, I had files example-chaincode.js, example-chaincode.go and a compiled go chaincode named example-chaincode. After removing example-chaincode, I was able to successfully spin up the network and deploy the node chaincode.

I will separate the chaincodes into different sub-folders in the future.

Spencer


From: White, Spencer (S.)
Sent: Wednesday, October 30, 2019 3:00 PM
To: fabric@... <fabric@...>; hyperledger-fabric@... <hyperledger-fabric@...>
Subject: Channel Registration Failed
 
Hello,

I am getting "channel registration failed" when running peer chaincode instantiate, a similar error identified in these two JIRA issues: 
  1. https://jira.hyperledger.org/browse/FAB-14741
  2. https://jira.hyperledger.org/browse/FAB-14638
Any advice? The issues are closed. I am able to deploy a go chaincode in the network, but not a node chaincode.

Node Version: 10.15.3
NPM Version: 6.4.1
Go Version: go1.11 darwin/amd64


Spencer


Re: Hyperledger Fabric Deployment on kubernetes #fabric-kubernetes #fabric

Hakan Eryargi
 

Hi Suresh,

Check this one:
https://github.com/APGGroeiFabriek/PIVT  

It's the most convenient way of running Fabric in Kube as of now.

Best,
Hakan

On Mon, Nov 4, 2019 at 2:59 PM suresh <tedlasuresh@...> wrote:
Hi All,

How to deploy Hyperledger Fabric Network on Kubernetes. can anyone provide docs for the same

Thanks
Suresh


Re: Hyperledger Fabric Deployment on kubernetes #fabric-kubernetes #fabric

Tong Li
 

Suresh,
Please take a look at the document here, https://github.com/hyperledger/cello/blob/master/docs/agents/ansible.md
I also attach this net work spec file for your reference. This network spec file defined 3 node raft orderering system, two peer orgs, each with 2 peers and use fabric release 1.4.3. You can add or remove nodes in the fabricnet section before you use it to stand up the fabric network. Please use the instructions documented in the above link. let me know if you run into errors. You can always find me on rocket chat in cello channel.

(See attached file: fabricspec.yml)

Tong Li
IBM Open Technology

"suresh" ---11/04/2019 09:00:23 AM---Hi All, How to deploy Hyperledger Fabric Network on Kubernetes. can anyone provide docs for the same

From: "suresh" <tedlasuresh@...>
To: fabric@...
Date: 11/04/2019 09:00 AM
Subject: [EXTERNAL] [Hyperledger Fabric] Hyperledger Fabric Deployment on kubernetes #fabric-kubernetes #fabric
Sent by: fabric@...





Hi All,

How to deploy Hyperledger Fabric Network on Kubernetes. can anyone provide docs for the same

Thanks
Suresh




Hyperledger Fabric Deployment on kubernetes #fabric-kubernetes #fabric

suresh <tedlasuresh@...>
 

Hi All,

How to deploy Hyperledger Fabric Network on Kubernetes. can anyone provide docs for the same

Thanks
Suresh


Re: Alternative of cryptogen for Prod

Nye Liu <nye@...>
 

It is described in the Operations Guide.

On 11/3/2019 1:11 AM, Abhijeet Bhowmik wrote:

Hey,

Just to be specific, I was referring to the certificates that we set up at peers and place public keys at orderer. From where do we obtain that folder structure (MSP and TLS)?

Thanks and Regards
Abhijeet Bhowmik

On Sun, Nov 3, 2019 at 10:44 AM Mrudav Shukla <mrudavshukla@...> wrote:
Hi Abhijeet,

For prod, you’ll need to generate certs from CAs. References:
Cheers,
Mrudav 

On Sun, 3 Nov 2019 at 10:22 AM, Abhijeet Bhowmik <abhijeet@...> wrote:
Greetings Everyone,

I am dwelling in the answer of the question: "If not cryptogen in Prod, then what and how?".
Right now, generating org certificates is a pretty straightforward task while getting started with HLF. But after reading the docs, the question has been thrown upon me that how can we configure certificates in Prod. I know it's a naive question to ask but being a beginner and stepping my first foot into actually hosting fabric application, I am obliged to ask the community to help me out.


Thanks and Regards
Abhijeet Bhowmik


Re: Alternative of cryptogen for Prod

Abhijeet Bhowmik <abhijeet@...>
 

Hey,

Just to be specific, I was referring to the certificates that we set up at peers and place public keys at orderer. From where do we obtain that folder structure (MSP and TLS)?

Thanks and Regards
Abhijeet Bhowmik

On Sun, Nov 3, 2019 at 10:44 AM Mrudav Shukla <mrudavshukla@...> wrote:
Hi Abhijeet,

For prod, you’ll need to generate certs from CAs. References:
Cheers,
Mrudav 

On Sun, 3 Nov 2019 at 10:22 AM, Abhijeet Bhowmik <abhijeet@...> wrote:
Greetings Everyone,

I am dwelling in the answer of the question: "If not cryptogen in Prod, then what and how?".
Right now, generating org certificates is a pretty straightforward task while getting started with HLF. But after reading the docs, the question has been thrown upon me that how can we configure certificates in Prod. I know it's a naive question to ask but being a beginner and stepping my first foot into actually hosting fabric application, I am obliged to ask the community to help me out.


Thanks and Regards
Abhijeet Bhowmik


Alternative of cryptogen for Prod

Abhijeet Bhowmik <abhijeet@...>
 

Greetings Everyone,

I am dwelling in the answer of the question: "If not cryptogen in Prod, then what and how?".
Right now, generating org certificates is a pretty straightforward task while getting started with HLF. But after reading the docs, the question has been thrown upon me that how can we configure certificates in Prod. I know it's a naive question to ask but being a beginner and stepping my first foot into actually hosting fabric application, I am obliged to ask the community to help me out.


Thanks and Regards
Abhijeet Bhowmik


Re: Major security hole in Hyperledger Fabric - Private Data is not private #fabric-chaincode #ssl #fabric #fabric-questions #fabric-dstorage

Yacov
 

I think that there are factors that people tend to overlook and it leads to frustration and questions such as: "I can do X easily in my cloud environment, why is it so complex to do it in Fabric?"
  1. Blockchains are often deployed in a non fully trusted environment where parties might even be competitors, and have incentives to be covertly malicious.
    This means that you can't assume the existence of a system that has a centralized administration.

    Sure, you can deploy Fabric in a setting where you have an organization that is trusted to perform some functions correctly (did anyone say Crash Fault Tolerant consensus ? ) if the parties in the network agree to it,
    however you wouldn't want a Blockchain project to depend on such a thing because it would severely limit its usefulness and would reduce the business problems it can solve.

    As a direct consequence, there are some things that are easily done in the cloud but are much more complex to do in Fabric, an obvious example would be - you need the consent of several parties to approve policies, and a non obvious example would be, that if you got a "discovery protocol" message from a party (say party A), it is possible that you can't just naively forward it to party B (as is implemented in many cloud native products), because it might be that party B should not even know the fact that you have a business relation with party A in the first place.
  2. It's true that nowadays it is very common to containerize everything and run it on Kubernetes, however to maximize adoption, Fabric should be deployable in every setup: Bare metal, docker compose / swarm, k8s, and the next cloud orchestration engine that is going to come out next year as well.

    Now, since not every user is a security expert, Fabric has to have built in security to protect itself so it can run in the simple primitive deployments where you don't have an Istio mesh to control which containers can communicate and which can't.

    So, these security mechanisms are sometimes not easy to integrate with your advanced environment, but there are efforts to make Fabric more cloud friendly (such as the server-side chaincode model, and the latest external builders which is supposed to give administrators more flexibility in how the chaincode is being run) .
- Yacov



From:        "Brian Behlendorf" <bbehlendorf@...>
To:        fabric@...
Date:        10/31/2019 09:19 PM
Subject:        [EXTERNAL] Re: [Hyperledger Fabric] Major security hole in Hyperledger Fabric - Private Data is not private #fabric #fabric-questions #fabric-dstorage #database #dstorage #dstorage-fabric #fabric-chaincode #ssl
Sent by:        fabric@...




Would libp2p be helpful here?  I had a conversation with someone about how other blockchain projects use it to abstract away some of the issues with using gossip for networking between nodes and how it simplifies the dev experience. 

Brian


On 10/31/19 11:43 AM, Nye Liu wrote:

Yes, i have extensive hacks that do exactly that. It's a mess and illustrates exactly how badly some of k8s networking is "designed".

On 10/31/2019 11:38 AM, Alexandre Pauwels wrote:
You should be able to leverage coredns rewrites to avoid hairpinning traffic.

Alex

On Thu, Oct 31, 2019 at 2:18 PM Nye Liu <nye@...> wrote:
Unfortunately, the internal DNS inside of a k8s cluster is completely screwed up since a service can't have more than two dots in them w/o a hairpin and external DNS resolution (e.g. host.subdomain.domain.foo)

On 10/31/2019 10:42 AM, Alexandre Pauwels wrote:
There should be no issue using k8s for Fabric gossip, and there should be no reason you need to expose anything other than port 443 externally. Expose your endpoints as subdomains on 443 and map those subdomains to appropriate ports internally. K8s has all the tools required to setup a network in this manner.

Alex

On Thu, Oct 31, 2019 at 11:55 AM Nye Liu <nye@...> wrote:
I had this issue as well with k8s.

k8s is a disaster for p2p protocols, it is a very bad match. Great for monolithic microservice stacks, not much else.

On 10/31/2019 7:20 AM, email4tong@...wrote:
Yacov,
  When get stuff running on k8s and behind load balancer or proxy, you do not get chance to use port 7051. As a matter of fact, on k8s in majority of cases your port wont be 7051, that does not mean other ports are not open. Just saying that we should not assume that it will be always port 7051.

On Thursday, October 31, 2019, 9:33:59 AM EDT, Yacov <yacovm@...>wrote:


If you have trouble opening ports between companies, you shouldn't use a Blockchain at all, since Blockchain is a decentralized peer to peer protocol.

All peer to peer communication works through the same port (7051 by default), it's not like you need to open extra ports.




From:        
arnes_chuzf@...
To:        
fabric@...
Date:        
10/31/2019 03:27 PM
Subject:        
[EXTERNAL] Re: [Hyperledger Fabric] Major security hole in Hyperledger Fabric - Private Data is not private #fabric #fabric-questions #fabric-dstorage #database #dstorage #dstorage-fabric #fabric-chaincode #ssl
Sent by:        
fabric@...





Hi Dave,  Alexandre,  Yacov, Ivan

I think private data’s p2p connection is a real problem (partially agree with Ivan).

In some commercial scenario, we need to open firewalls for every company connecting to each other, which is a disaster for project deployment.
 
And that is not the end of story. When a new company needs to join the existing fabric network, it needs to connect to each company. Again, we need to open firewalls, not only for the one newly joining, but also for those already joined. Hard to explain to everyone why a new company joining leads to such a tremendous configuration change. You don’t know how terrible it is you get challenged by IT departments of those companies ONE BY ONE, and you have no solution.
 
Do you have solution for such issue?
 
Thank you all


--
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf





Documentation Workgroup: Agenda for Friday, 01 November

Anthony O'Dowd <a_o-dowd@...>
 

Hello All,

We hold our regular documentation workgroup call this week, both Eastern and Western hemispheres. Please note that if you're calling in from Europe both calls are an hour earlier this week as the US shifts their clocks this coming weekend.

As is now usual, you can see the new Wiki page : https://wiki.hyperledger.org/display/fabric/Documentation+Working+Group

You can read the summary minutes for last week's call and see this week's agenda :https://wiki.hyperledger.org/display/fabric/2019+11+01+DWG+Agenda We've also added an outline agenda for next week's meeting : https://wiki.hyperledger.org/display/fabric/2019+11+08+DWG+Agenda Feel free to add items to this as required.

Best regards,

Anthony, Pam, Joe, Nik

P.S We will include meeting details below for continuity for the next few weeks.

Meeting Details
-------------
Please use the following link to attend the meeting:  https://zoom.us/j/6223336701

Zoom should work in the browser.  We will open the call 5 minutes early so that folks can test it out. We'll also monitor the RocketChat at https://chat.hyperledger.org/channel/fabric-release so that if anyone has issues, ping me there!

More Zoom connection options at the bottom of this note.

The meeting times are as follows:


Meeting 103A: Friday 01 Nov
                   1130 India Standard Time
                   1400 China Standard Time
                   1500 Japan Standard Time
                   1700 Australia Eastern Time
                   1400 Singapore Time
                   1000 Gulf Standard Time
                   0900 Moscow Standard Time
                   0600 Greenwich Mean Time
                   0700 Central European Time    

Meeting 103B: Friday 01 Nov
              1000 Central Daylight Time
                   1100 Eastern Daylight Time
                   0800 Pacific Daylight Time
                   1200 Brasil Standard Time
                   1500 Greenwich Mean Time
                   1600 Central European Time
                   1700 Moscow Standard Time



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


Re: Major security hole in Hyperledger Fabric - Private Data is not private #fabric-chaincode #ssl #fabric #fabric-questions #fabric-dstorage

Brian Behlendorf <bbehlendorf@...>
 

Would libp2p be helpful here?  I had a conversation with someone about how other blockchain projects use it to abstract away some of the issues with using gossip for networking between nodes and how it simplifies the dev experience. 

Brian

On 10/31/19 11:43 AM, Nye Liu wrote:

Yes, i have extensive hacks that do exactly that. It's a mess and illustrates exactly how badly some of k8s networking is "designed".

On 10/31/2019 11:38 AM, Alexandre Pauwels wrote:
You should be able to leverage coredns rewrites to avoid hairpinning traffic.

Alex

On Thu, Oct 31, 2019 at 2:18 PM Nye Liu <nye@...> wrote:

Unfortunately, the internal DNS inside of a k8s cluster is completely screwed up since a service can't have more than two dots in them w/o a hairpin and external DNS resolution (e.g. host.subdomain.domain.foo)

On 10/31/2019 10:42 AM, Alexandre Pauwels wrote:
There should be no issue using k8s for Fabric gossip, and there should be no reason you need to expose anything other than port 443 externally. Expose your endpoints as subdomains on 443 and map those subdomains to appropriate ports internally. K8s has all the tools required to setup a network in this manner.

Alex

On Thu, Oct 31, 2019 at 11:55 AM Nye Liu <nye@...> wrote:

I had this issue as well with k8s.

k8s is a disaster for p2p protocols, it is a very bad match. Great for monolithic microservice stacks, not much else.

On 10/31/2019 7:20 AM, email4tong@... wrote:
Yacov,
  When get stuff running on k8s and behind load balancer or proxy, you do not get chance to use port 7051. As a matter of fact, on k8s in majority of cases your port wont be 7051, that does not mean other ports are not open. Just saying that we should not assume that it will be always port 7051.

On Thursday, October 31, 2019, 9:33:59 AM EDT, Yacov <yacovm@...> wrote:


If you have trouble opening ports between companies, you shouldn't use a Blockchain at all, since Blockchain is a decentralized peer to peer protocol.

All peer to peer communication works through the same port (7051 by default), it's not like you need to open extra ports.



From:        arnes_chuzf@...
To:        fabric@...
Date:        10/31/2019 03:27 PM
Subject:        [EXTERNAL] Re: [Hyperledger Fabric] Major security hole in Hyperledger Fabric - Private Data is not private #fabric #fabric-questions #fabric-dstorage #database #dstorage #dstorage-fabric #fabric-chaincode #ssl
Sent by:        fabric@...




Hi Dave,  Alexandre,  Yacov, Ivan

I think private data’s p2p connection is a real problem (partially agree with Ivan).

In some commercial scenario, we need to open firewalls for every company connecting to each other, which is a disaster for project deployment.
 
And that is not the end of story. When a new company needs to join the existing fabric network, it needs to connect to each company. Again, we need to open firewalls, not only for the one newly joining, but also for those already joined. Hard to explain to everyone why a new company joining leads to such a tremendous configuration change. You don’t know how terrible it is you get challenged by IT departments of those companies ONE BY ONE, and you have no solution.
 
Do you have solution for such issue?
 
Thank you all




-- 
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf


Re: Major security hole in Hyperledger Fabric - Private Data is not private #fabric-chaincode #ssl #fabric #fabric-questions #fabric-dstorage

Nye Liu <nye@...>
 

Yes, i have extensive hacks that do exactly that. It's a mess and illustrates exactly how badly some of k8s networking is "designed".

On 10/31/2019 11:38 AM, Alexandre Pauwels wrote:

You should be able to leverage coredns rewrites to avoid hairpinning traffic.

Alex

On Thu, Oct 31, 2019 at 2:18 PM Nye Liu <nye@...> wrote:

Unfortunately, the internal DNS inside of a k8s cluster is completely screwed up since a service can't have more than two dots in them w/o a hairpin and external DNS resolution (e.g. host.subdomain.domain.foo)

On 10/31/2019 10:42 AM, Alexandre Pauwels wrote:
There should be no issue using k8s for Fabric gossip, and there should be no reason you need to expose anything other than port 443 externally. Expose your endpoints as subdomains on 443 and map those subdomains to appropriate ports internally. K8s has all the tools required to setup a network in this manner.

Alex

On Thu, Oct 31, 2019 at 11:55 AM Nye Liu <nye@...> wrote:

I had this issue as well with k8s.

k8s is a disaster for p2p protocols, it is a very bad match. Great for monolithic microservice stacks, not much else.

On 10/31/2019 7:20 AM, email4tong@... wrote:
Yacov,
  When get stuff running on k8s and behind load balancer or proxy, you do not get chance to use port 7051. As a matter of fact, on k8s in majority of cases your port wont be 7051, that does not mean other ports are not open. Just saying that we should not assume that it will be always port 7051.

On Thursday, October 31, 2019, 9:33:59 AM EDT, Yacov <yacovm@...> wrote:


If you have trouble opening ports between companies, you shouldn't use a Blockchain at all, since Blockchain is a decentralized peer to peer protocol.

All peer to peer communication works through the same port (7051 by default), it's not like you need to open extra ports.



From:        arnes_chuzf@...
To:        fabric@...
Date:        10/31/2019 03:27 PM
Subject:        [EXTERNAL] Re: [Hyperledger Fabric] Major security hole in Hyperledger Fabric - Private Data is not private #fabric #fabric-questions #fabric-dstorage #database #dstorage #dstorage-fabric #fabric-chaincode #ssl
Sent by:        fabric@...




Hi Dave,  Alexandre,  Yacov, Ivan

I think private data’s p2p connection is a real problem (partially agree with Ivan).

In some commercial scenario, we need to open firewalls for every company connecting to each other, which is a disaster for project deployment.
 
And that is not the end of story. When a new company needs to join the existing fabric network, it needs to connect to each company. Again, we need to open firewalls, not only for the one newly joining, but also for those already joined. Hard to explain to everyone why a new company joining leads to such a tremendous configuration change. You don’t know how terrible it is you get challenged by IT departments of those companies ONE BY ONE, and you have no solution.
 
Do you have solution for such issue?
 
Thank you all




Re: Major security hole in Hyperledger Fabric - Private Data is not private #fabric-chaincode #ssl #fabric #fabric-questions #fabric-dstorage

Alexandre Pauwels
 

You should be able to leverage coredns rewrites to avoid hairpinning traffic.

Alex


On Thu, Oct 31, 2019 at 2:18 PM Nye Liu <nye@...> wrote:

Unfortunately, the internal DNS inside of a k8s cluster is completely screwed up since a service can't have more than two dots in them w/o a hairpin and external DNS resolution (e.g. host.subdomain.domain.foo)

On 10/31/2019 10:42 AM, Alexandre Pauwels wrote:
There should be no issue using k8s for Fabric gossip, and there should be no reason you need to expose anything other than port 443 externally. Expose your endpoints as subdomains on 443 and map those subdomains to appropriate ports internally. K8s has all the tools required to setup a network in this manner.

Alex

On Thu, Oct 31, 2019 at 11:55 AM Nye Liu <nye@...> wrote:

I had this issue as well with k8s.

k8s is a disaster for p2p protocols, it is a very bad match. Great for monolithic microservice stacks, not much else.

On 10/31/2019 7:20 AM, email4tong@... wrote:
Yacov,
  When get stuff running on k8s and behind load balancer or proxy, you do not get chance to use port 7051. As a matter of fact, on k8s in majority of cases your port wont be 7051, that does not mean other ports are not open. Just saying that we should not assume that it will be always port 7051.

On Thursday, October 31, 2019, 9:33:59 AM EDT, Yacov <yacovm@...> wrote:


If you have trouble opening ports between companies, you shouldn't use a Blockchain at all, since Blockchain is a decentralized peer to peer protocol.

All peer to peer communication works through the same port (7051 by default), it's not like you need to open extra ports.



From:        arnes_chuzf@...
To:        fabric@...
Date:        10/31/2019 03:27 PM
Subject:        [EXTERNAL] Re: [Hyperledger Fabric] Major security hole in Hyperledger Fabric - Private Data is not private #fabric #fabric-questions #fabric-dstorage #database #dstorage #dstorage-fabric #fabric-chaincode #ssl
Sent by:        fabric@...




Hi Dave,  Alexandre,  Yacov, Ivan

I think private data’s p2p connection is a real problem (partially agree with Ivan).

In some commercial scenario, we need to open firewalls for every company connecting to each other, which is a disaster for project deployment.
 
And that is not the end of story. When a new company needs to join the existing fabric network, it needs to connect to each company. Again, we need to open firewalls, not only for the one newly joining, but also for those already joined. Hard to explain to everyone why a new company joining leads to such a tremendous configuration change. You don’t know how terrible it is you get challenged by IT departments of those companies ONE BY ONE, and you have no solution.
 
Do you have solution for such issue?
 
Thank you all




Re: Major security hole in Hyperledger Fabric - Private Data is not private #fabric-chaincode #ssl #fabric #fabric-questions #fabric-dstorage

Nye Liu <nye@...>
 

Unfortunately, the internal DNS inside of a k8s cluster is completely screwed up since a service can't have more than two dots in them w/o a hairpin and external DNS resolution (e.g. host.subdomain.domain.foo)

On 10/31/2019 10:42 AM, Alexandre Pauwels wrote:

There should be no issue using k8s for Fabric gossip, and there should be no reason you need to expose anything other than port 443 externally. Expose your endpoints as subdomains on 443 and map those subdomains to appropriate ports internally. K8s has all the tools required to setup a network in this manner.

Alex

On Thu, Oct 31, 2019 at 11:55 AM Nye Liu <nye@...> wrote:

I had this issue as well with k8s.

k8s is a disaster for p2p protocols, it is a very bad match. Great for monolithic microservice stacks, not much else.

On 10/31/2019 7:20 AM, email4tong@... wrote:
Yacov,
  When get stuff running on k8s and behind load balancer or proxy, you do not get chance to use port 7051. As a matter of fact, on k8s in majority of cases your port wont be 7051, that does not mean other ports are not open. Just saying that we should not assume that it will be always port 7051.

On Thursday, October 31, 2019, 9:33:59 AM EDT, Yacov <yacovm@...> wrote:


If you have trouble opening ports between companies, you shouldn't use a Blockchain at all, since Blockchain is a decentralized peer to peer protocol.

All peer to peer communication works through the same port (7051 by default), it's not like you need to open extra ports.



From:        arnes_chuzf@...
To:        fabric@...
Date:        10/31/2019 03:27 PM
Subject:        [EXTERNAL] Re: [Hyperledger Fabric] Major security hole in Hyperledger Fabric - Private Data is not private #fabric #fabric-questions #fabric-dstorage #database #dstorage #dstorage-fabric #fabric-chaincode #ssl
Sent by:        fabric@...




Hi Dave,  Alexandre,  Yacov, Ivan

I think private data’s p2p connection is a real problem (partially agree with Ivan).

In some commercial scenario, we need to open firewalls for every company connecting to each other, which is a disaster for project deployment.
 
And that is not the end of story. When a new company needs to join the existing fabric network, it needs to connect to each company. Again, we need to open firewalls, not only for the one newly joining, but also for those already joined. Hard to explain to everyone why a new company joining leads to such a tremendous configuration change. You don’t know how terrible it is you get challenged by IT departments of those companies ONE BY ONE, and you have no solution.
 
Do you have solution for such issue?
 
Thank you all




Re: Major security hole in Hyperledger Fabric - Private Data is not private #fabric-chaincode #ssl #fabric #fabric-questions #fabric-dstorage

Alexandre Pauwels
 

There should be no issue using k8s for Fabric gossip, and there should be no reason you need to expose anything other than port 443 externally. Expose your endpoints as subdomains on 443 and map those subdomains to appropriate ports internally. K8s has all the tools required to setup a network in this manner.

Alex


On Thu, Oct 31, 2019 at 11:55 AM Nye Liu <nye@...> wrote:

I had this issue as well with k8s.

k8s is a disaster for p2p protocols, it is a very bad match. Great for monolithic microservice stacks, not much else.

On 10/31/2019 7:20 AM, email4tong@... wrote:
Yacov,
  When get stuff running on k8s and behind load balancer or proxy, you do not get chance to use port 7051. As a matter of fact, on k8s in majority of cases your port wont be 7051, that does not mean other ports are not open. Just saying that we should not assume that it will be always port 7051.

On Thursday, October 31, 2019, 9:33:59 AM EDT, Yacov <yacovm@...> wrote:


If you have trouble opening ports between companies, you shouldn't use a Blockchain at all, since Blockchain is a decentralized peer to peer protocol.

All peer to peer communication works through the same port (7051 by default), it's not like you need to open extra ports.



From:        arnes_chuzf@...
To:        fabric@...
Date:        10/31/2019 03:27 PM
Subject:        [EXTERNAL] Re: [Hyperledger Fabric] Major security hole in Hyperledger Fabric - Private Data is not private #fabric #fabric-questions #fabric-dstorage #database #dstorage #dstorage-fabric #fabric-chaincode #ssl
Sent by:        fabric@...




Hi Dave,  Alexandre,  Yacov, Ivan

I think private data’s p2p connection is a real problem (partially agree with Ivan).

In some commercial scenario, we need to open firewalls for every company connecting to each other, which is a disaster for project deployment.
 
And that is not the end of story. When a new company needs to join the existing fabric network, it needs to connect to each company. Again, we need to open firewalls, not only for the one newly joining, but also for those already joined. Hard to explain to everyone why a new company joining leads to such a tremendous configuration change. You don’t know how terrible it is you get challenged by IT departments of those companies ONE BY ONE, and you have no solution.
 
Do you have solution for such issue?
 
Thank you all




Re: Major security hole in Hyperledger Fabric - Private Data is not private #fabric-chaincode #ssl #fabric #fabric-questions #fabric-dstorage

Nye Liu <nye@...>
 

I had this issue as well with k8s.

k8s is a disaster for p2p protocols, it is a very bad match. Great for monolithic microservice stacks, not much else.

On 10/31/2019 7:20 AM, email4tong@... wrote:

Yacov,
  When get stuff running on k8s and behind load balancer or proxy, you do not get chance to use port 7051. As a matter of fact, on k8s in majority of cases your port wont be 7051, that does not mean other ports are not open. Just saying that we should not assume that it will be always port 7051.

On Thursday, October 31, 2019, 9:33:59 AM EDT, Yacov <yacovm@...> wrote:


If you have trouble opening ports between companies, you shouldn't use a Blockchain at all, since Blockchain is a decentralized peer to peer protocol.

All peer to peer communication works through the same port (7051 by default), it's not like you need to open extra ports.



From:        arnes_chuzf@...
To:        fabric@...
Date:        10/31/2019 03:27 PM
Subject:        [EXTERNAL] Re: [Hyperledger Fabric] Major security hole in Hyperledger Fabric - Private Data is not private #fabric #fabric-questions #fabric-dstorage #database #dstorage #dstorage-fabric #fabric-chaincode #ssl
Sent by:        fabric@...




Hi Dave,  Alexandre,  Yacov, Ivan

I think private data’s p2p connection is a real problem (partially agree with Ivan).

In some commercial scenario, we need to open firewalls for every company connecting to each other, which is a disaster for project deployment.
 
And that is not the end of story. When a new company needs to join the existing fabric network, it needs to connect to each company. Again, we need to open firewalls, not only for the one newly joining, but also for those already joined. Hard to explain to everyone why a new company joining leads to such a tremendous configuration change. You don’t know how terrible it is you get challenged by IT departments of those companies ONE BY ONE, and you have no solution.
 
Do you have solution for such issue?
 
Thank you all




Re: Major security hole in Hyperledger Fabric - Private Data is not private #fabric-chaincode #ssl #fabric #fabric-questions #fabric-dstorage

Yacov
 

My point with 7051 was merely to say that there is only a single port that you need to map via a port forwarding rule in a firewall, not several.




From:        "email4tong@..." <email4tong@...>
To:        
Cc:        fabric@...
Date:        10/31/2019 04:21 PM
Subject:        [EXTERNAL] Re: [Hyperledger Fabric] Major security hole in Hyperledger Fabric - Private Data is not private #fabric #fabric-questions #fabric-dstorage #database #dstorage #dstorage-fabric #fabric-chaincode #ssl
Sent by:        fabric@...




Yacov,
  When get stuff running on k8s and behind load balancer or proxy, you do not get chance to use port 7051. As a matter of fact, on k8s in majority of cases your port wont be 7051, that does not mean other ports are not open. Just saying that we should not assume that it will be always port 7051.

On Thursday, October 31, 2019, 9:33:59 AM EDT, Yacov <yacovm@...> wrote:


If you have trouble opening ports between companies, you shouldn't use a Blockchain at all, since Blockchain is a decentralized peer to peer protocol.

All peer to peer communication works through the same port (7051 by default), it's not like you need to open extra ports.




From:        
arnes_chuzf@...
To:        
fabric@...
Date:        
10/31/2019 03:27 PM
Subject:        
[EXTERNAL] Re: [Hyperledger Fabric] Major security hole in Hyperledger Fabric - Private Data is not private #fabric #fabric-questions #fabric-dstorage #database #dstorage #dstorage-fabric #fabric-chaincode #ssl
Sent by:        
fabric@...




Hi Dave,  Alexandre,  Yacov, Ivan


I think private data’s p2p connection is a real problem (partially agree with Ivan).

In some commercial scenario, we need to open firewalls for every company connecting to each other, which is a disaster for project deployment.

And that is not the end of story. When a new company needs to join the existing fabric network, it needs to connect to each company. Again, we need to open firewalls, not only for the one newly joining, but also for those already joined. Hard to explain to everyone why a new company joining leads to such a tremendous configuration change. You don’t know how terrible it is you get challenged by IT departments of those companies ONE BY ONE, and you have no solution.

Do you have solution for such issue?

Thank you all







4441 - 4460 of 11518