You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a mitigation plan for #2 while the solution is implemented, the use of NetworkPolicies to limit ingress traffic to the Endorser instances. The work is being tracked here: #100
A concern being raised is this this approach would require private endpoints to be published to the ledger, since the discovery of the endorser agent happens by public DID, and this would not be desirable.
A stop-gap option that could allow us to move forward without having to implement temporary ad-hoc patches, would be to manually set-up the connection to the endorser agent, since this is a one-time procedure and it will likely only be necessary for one or two agents at most.
Traction determines if the agent is connected to an endorser by the connection alias, specified at deployment time.
Not including the endorser public DID will prevent tenants from initiating a connection request.
Manually accepting a connection request from the endorser in the Traction tenant using the expected alias, and setting the connection metadata role as author for the tenant (this is what the Traction plug-in is doing), should result in an active connection with the endorser being recognized by the tenant.
Endorsement of publishing the DID as well as creating a schema should work seamlessly assuming the appropriate configuration flags were set at the endorser level.
The ticket is to evaluate and validate that this approach would work and be a feasible temporary alternative in production until the granular endorser configuration work is completed and deployed.
The text was updated successfully, but these errors were encountered:
The scripts are well documented and contain links to the "official" documentation on the subject. These can be used, at least, to inform the process. The scripts initiate the connection between the author and endorser and then configure the endorser settings at the connection level, allowing the settings at the global level to remain manual/private.
As part of our plan to move Traction to production use, we need the process of connecting to an endorser to be:
As a mitigation plan for #2 while the solution is implemented, the use of
NetworkPolicies
to limit ingress traffic to the Endorser instances. The work is being tracked here: #100A concern being raised is this this approach would require private endpoints to be published to the ledger, since the discovery of the endorser agent happens by public DID, and this would not be desirable.
A stop-gap option that could allow us to move forward without having to implement temporary ad-hoc patches, would be to manually set-up the connection to the endorser agent, since this is a one-time procedure and it will likely only be necessary for one or two agents at most.
author
for the tenant (this is what the Traction plug-in is doing), should result in an active connection with the endorser being recognized by the tenant.The ticket is to evaluate and validate that this approach would work and be a feasible temporary alternative in production until the granular endorser configuration work is completed and deployed.
The text was updated successfully, but these errors were encountered: