Develop custom policy for secure communication between RSBC Hub and RSBC BI API namespaces in DEV and TEST environments in PROD OCP cluster

[tosazuwa]

RSI-1402 - Inter-namespace communication for Justice Hub (eTicketing product name for RSBC Hub Applications) RSBC Hub (jik2hd) and RSBC BI (??), from Hub to BI

Who: Hub operators – maintain Data Hub, BI Analysts – use Bi application to manage data and derive insights. Both apps are Java based

What: Enable real time high security integration between apps. API will be open in one app that the other can consume, the API should be protected by Aporeto.

Why: Right now the two apps can only communicate via a manually driven batch feed that runs on a weekly cycle.

Both apps are running in the Openshift PROD.

Tasks:

• [x] Aporeto installed and enabled in LAB.
• [x] Operator is installed in LAB
• [x] Open an API Endpoint in RSBC BI
• [ ] Training session for RoadSafetyBC pilot team
• [ ] Develop a custom Aporeto policy and add in deployment descriptor
• [ ] Test the connection and sign off

Acceptance criteria :

• [ ] Technical – application A can invoke an API endpoint in the application B, all communications are secure and encrypted with OCP self-signed certificates (HTTPS connection) and Aporeto policy enforced.

• [ ] Ministry/Sector compliance – STRA/PIA signed off

Requirements Clarification from David A- Monday Oct 28th 2019 • Network join the RSBC Hub (namespace id = jik2hd) and RSBC BI (namespace id = iowaey) in Dev and Test so that pods in both name spaces can communicate in each environment (Dev to Dev, Test to Test) • Example custom policy to support the following interaction pattern between two deployment instances from RSBC Hub and bi-hub-apiadapter from RSBC BI). See below:

Example custom policy exclude any other communication between the two namesapces

[tosazuwa]

This is a unique Aporeto use case we’re adding to the security project - app to app integration across two different project namespaces in OpenShift

[jleach]

Didn't get too much done with David on Thursday because of an issue with BC Registries doing namespace to namespace communication. This was resulted and they proved we can do this just fine.

I think there may be a misunderstanding about this task: Its frowned uppon for namespace to be joined so they can talk to one another. The correct pattern is to create an API that exposes a service so that it can be used by other services regardless of what namespace they are in.

In addition, you can add whitelist on the API route to limit access to just the cluster. In addition to this (or as an alternative) we can now use Aporeto to limit access based on labels. This means that even though the API is accessible to the entire cluster IP (or more) Aporeto will limit access to specific pods et al.

We need to confirm with David that we can use the above mentioned pattern and not join the two namespaces.

[jleach]

Because of the issue on Thrusday David and myself will sit down another time and work on the custom policy.

[tosazuwa]

@jleach , i will reach out to David to ensure he attends Sprint Planning next week so we can clarify the requirements and confirm a decision on the above mentioned pattern.

[jleach]

@tosazuwa I can work with him when I'm back. I feel like we're creating too many meetings for our pilots when we can just chant 1-1 via RocketChat as needed.

[tosazuwa]

@jleach , sounds good. I will leave this with you

[tosazuwa]

@Jleach. Requirements clarification from David:

• Network join the RSBC Hub (namespace id = jik2hd) and RSBC BI (namespace id = iowaey) in Dev and Test so that pods in both name spaces can communicate in each environment (Dev to Dev, Test to Test) • Example custom policy to support the following interaction pattern between two deployment instances (jh-rte-api from RSBC Hub and bi-hub-apiadapter from RSBC BI). See below:

rsi 1a.jpg

Example custom policy exclude any other communication between the two namesapces

[jleach]

I'm gong to close this issue. I worked with the team and we developed policy demonstrating how to establish secure namespace to namespace communication. It is now up to the team to develop their custom policy as they see fit.