QA: FsR: Detail Implementation plan to support injecting SLB CA chain into Drillflow

[niaalex]

Detail Implementation plan to remove the DoT WITSML endpoints from API gateway publishing.

This card is created to track the plan to support injecting SLB CA chain intro Drillflow in order to enable connecting Drillflow to DoT internal endpoints rather than current public endpoints and thus remove the DoT WITSML endpoints from API gateway publishing.

Detailed information was provided in PDF form via slack msx from Shuping at [1:09 AM] cst 7/29.

The action is to detail the plan for this implementation.

[TessForGithub2]

Update: So is this higher priority than Design Document, which I was given 1 day to accomplish tomorrow? Is this higher than UpdateFromStore for FluidsReport? What about Logs 1.3.1.1 fixes?

[niaalex]

I think the ask is to just provide the plan in reply for implementation not to actually do the implementation.

@Mike-d-s please advise how this should be prioritized and who it should be assigned to. The current team may need more detail on the background for this one.

[niaalex]

This card is connected to the certificate question from earlier and the ability to inject the SLB certificate for the container.

Then we need to look at the different between the DMZ exposed endpoint URLs and the ones internal to DOT behind the gateway.

The two questions we have to look into are whether there is any change to the URL injection method for the container config and then validate the ability to inject the new certificate chain to be able to authenticate behind the API gateway.

Who will manage this card?

[niaalex]

I have renamed the card per client request for note Detail Implementation plan to support injecting SLB CA chain into Drillflow in order to track the plan to allow drillflow to accept parameters to inject.

@TessForGithub2 is this one yours also?

[niaalex]

@shehzadsidi will update 8/2

[TessForGithub2]

It was agreed that Shehzad will manage this card.

Thank you,

Theresa Stewart 281.723.7108

On Fri, Aug 2, 2019 at 9:18 AM niaalex notifications@github.com wrote:

This card is connected to the certificate question from earlier and the ability to inject the SLB certificate for the container.

Then we need to look at the different between the DMZ exposed endpoint URLs and the ones internal to DOT behind the gateway.

The two questions we have to look into are whether there is any change to the URL injection method for the container config and then validate the ability to inject the new certificate chain to be able to authenticate behind the API gateway.

Who will manage this card?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/hashmapinc/Drillflow/issues/656?email_source=notifications&email_token=ALOO7TOGQHZJKEQ554HG3WTQCQ64HA5CNFSM4IHTLQK2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3N4A4I#issuecomment-517718129, or mute the thread https://github.com/notifications/unsubscribe-auth/ALOO7TKZKM5WWT2R7W7KOO3QCQ64HANCNFSM4IHTLQKQ .

[niaalex]

@shehzadsidi please advise the status of this card ASAP.

[niaalex]

Shehzad has confirmed that in order to understand the configuration changes in Drillflow so that this implementation is configurable we will require a follow up with the SLB team, a working session in order to identify the details of config changes.

We will propose adding some additional time to our presentation to review on the Monday status call.

[niaalex]

Shehzad has confirmed that in order to understand the changes in the configuration changes in Drillflow so that this implementation is configurable. We require a follow up with the SLB team in order to identify the details of config changes. Chris has also provided some recommendation on the SLB side. We will follow the updates.

[TessForGithub2]

UPDATE: Chris is advocating within the SLB team that they handle it. Email dated 8/15 at 8:21 AM: "So just to be clear, this is less of a drillflow issue and more of a linux issue. We are trying to add a trusted certificate. I have never seen a software package that modified the certificates on the OS directly as part of its core functionality (for a number of reasons) unless you are using a service/utility like letsencrypt (which we are not). My suggestion is, to take the easiest and most secure path which is for SLB to take the drillflow base image, and create a new layer which adds the certificate to the certificate store as mentioned in a previous email. Otherwise you are creating quite a complex solution to solve a simple problem (certificate trusting)."

We need to await SLB's response to their Global Architect. If they follow this path, I think this just becomes a collaboration on testing.

[niaalex]

The SLB team has provided an update on the FluidsReport URL Injection Issue

[niaalex]

@shehzadsidi is it ok to close this one?

[Mike-d-s]

As per the email, SLB team will wrap an additional layer around the container to handle the cert chain.