search

bcgov / DITP-DevOps

Digital Identity and Trust Program Team's DevOps Documentation Repository
Apache License 2.0
2 stars 5 forks source link

Implement NetworkPolicies to limit access to Candy Endorsers #100

Closed esune closed 12 months ago

esune commented 1 year ago

Current endorser do not have the ability to control endorsement requests based on an allow-list - see https://github.com/hyperledger/aries-endorser-service/issues/32.

As a stop-gap to allow transitioning to CANdy, implement NetworkPolicies to limit access to the CANdy endorsers only from the namespaces hosting Traction and other "official" issuers.

esune commented 1 year ago

Action plan: implement and validate endorser access restrictions and use the endorser for BCovrin Test connected to Traction dev to confirm the solution works as expected.

WadeBarnes commented 1 year ago

While performing a bit of exploratory investigation before getting too deep into things, I've been reminded that the connection between an author and endorser is initiated via the endorser's public DID, and therefore the endpoint registered on the ledger for that DID.

What we're proposing with this ticket is implementing OpenShift Network policies that allow services in separate namespaces to communicate internally. For example, an author in one namespace would be able to communicate to and endorser in another namespace using an internal (private) URL. The purpose is to allow us to disable public access to the endorsers so all communications are private and controlled, allowing us to open up automated connections and endorsement for select authors without additional development effort.

For this to work we would be registering private URLs on the ledger(s) for public DIDs, which introduces an anti-pattern. Further we've already established and registered public endpoints for the endorsers we've deployed. Updating those endpoints to something other than a more permanent and public vanity URL would look "wrong". On the CANdy network we already have the IDIM and BC VC Pilot agents registered with the endorser's public DID (endpoints) and the endorsement permissions configured at the connection level.

Based on this analysis I'm questioning this direction as a viable approach to our current situation.

swcurran commented 1 year ago

Would it be technically feasible to double down on the ugliness of the hack and on the fly change the URL from hard-code external URLs to an internal one? Definite hold the nose ugliness, but it just has to get us a few months. Only if it is a simple thing to do, obviously. We’re already working on the right fix.

WadeBarnes commented 1 year ago

I'm not sure I follow what you're suggesting.

swcurran commented 1 year ago

In Traction, at the time we go to use the Endorser URL, swap out the server URL with a different one — the internal openshift URL — for the call. Anyone trying to use the public URL would not be able to access the Endorser, and the internal openshift rules would work as planned in this Issue.

Code would have to be added, but if it was easy, we could just use the OpenShift rules as planned in this issue.

esune commented 1 year ago

In Traction, at the time we go to use the Endorser URL, swap out the server URL with a different one — the internal openshift URL — for the call. Anyone trying to use the public URL would not be able to access the Endorser, and the internal openshift rules would work as planned in this Issue.

Code would have to be added, but if it was easy, we could just use the OpenShift rules as planned in this issue.

The issue @WadeBarnes is referring to is that the internal, non-public URL would be posted onto the ledger. Posting the public URL to the ledger means that all of the "auto" flags would have to be turned off (as it is now), negating the automatic endorsement we need.

Additionally, I am not really a fan of adding what feels like a use-case specific hack to the codebase.

esune commented 1 year ago

Logged a spike to validate a theory that would allow us to set-up the endorsers to NOT accept connections by default and auto-endorse transactions without code changes on either endorser and Traction, while we wait for the granular configuration work to be completed.

esune commented 12 months ago

Closing this, will review/log the work resulting from https://app.zenhub.com/workspaces/bcgov-ditp-products-team-63c987121278d5001ecb177b/issues/gh/bcgov/ditp-devops/110