search

cityofaustin / atd-data-tech

Austin Transportation Data & Technology Services
17 stars 2 forks source link

Stand up test 1password connect server on enterprise 1pw #16372

Closed chiaberry closed 2 months ago

chiaberry commented 3 months ago

Stand up test 1password connect server on enterprise 1pw, and report feasibility

I wrote Bart L. today asking about how a 1PW Connect integration might look as well as asking if I could get access to the service to evaluate its impact on our team. I am seeking to establish a dialog with him about 1PW and to learn more about what the COA deployment looks like, in particular around the control of DTS vaults and if they reserve the right to administrate or access them. I'll follow up here as our conversation develops.

Originally posted by @frankhereford in https://github.com/cityofaustin/atd-data-tech/issues/11770#issuecomment-1964475966

frankhereford commented 3 months ago

TLDR

I don't have great news to report here. As it's configured, the COA 1Password service does not grant us authorization to create connect servers. I have verified this through both the web UI and via the 1Password CLI tooling. I am not deeply surprised that this is a restricted service as it's a pay-as-you-use type of add-on cost, but at the same time, I was hopeful.

Findings

Here is what the two accounts look like via the web UI.

COA Enterprise Account

Developer tools COA Enterprise

DTS Team Account

Developer tools DTS Team

The Connect service management is found under the "Other" button in the Infrastructure Secrets Management section of the Developer Tools page. It is not available to me under the COA Enterprise service.

This is confirmed using the 1Password CLI tooling:

❯ op --account <masked user ID> connect server create dts-test-account
[ERROR] 2024/03/26 08:38:30 (403) Forbidden: You aren't authorized to access this resource.

Other Considerations

With the exception of the connect service permission, I find that the enterprise account is sufficient in every way. I can imagine a world where we maintain a team account but only with a handful of team members (mgmt + devs) who manage the API driven secrets and the bulk of the users migrate to the enterprise service. The cost reduction and improved predictability about the number of seats needed under the DTS team account may make this an appealing consideration.

The above consideration is further improved by the degree of polish in the 1Password Desktop Application. Using multiple accounts is not only support, it's a absolute 1st class feature in the application. It could not be easier or more transparent, so those who need to move their secrets to the COA account would be able to do so in a drag-and-drop type of way, and those who had to manage and access both accounts would have no meaningful added work placed on them.

Possible Next Steps

If you'd like, I'd be happy to talk to Bart about what it would take to get that permission granted to my account on behalf of DTS and also perhaps to ask if the decision to restrict it was intentional or a default configuration.

dianamartin commented 3 months ago

@Frank Could we ask Bart what our options are for the "Connect Service Management" functionality?

frankhereford commented 3 months ago

@dianamartin wrote:

@frank Could we ask Bart what our options are for the "Connect Service Management" functionality?

100%; I'll write him an email tomorrow to open up that dialog. I'll let you know what I learn as soon as I hear back.

frankhereford commented 3 months ago

I sent him an email this morning asking if it would be possible to have permission to manage "Secrets Automation" added to my account, and I'll relay any information that I receive back. Thanks!

frankhereford commented 3 months ago

Bart wrote back today expressing a very positive sentiment about finding a way to make the connect server a reality for us. I am going to write him back 1st thing in the morning to firm up next steps and get us moving forward.

frankhereford commented 2 months ago

TLDR

We're good to move forward with setting up the connect server and everything is progressing as hoped.

Meeting Apr 16

We had a really great meeting today with Bart & Tarek from ISO. From our team, we had @maccallump , @chiaberry , @amenity and myself.

We introduced ourselves and caught up and discussed different ways of going about setting up the connect server in terms of user permissions. We all agreed that it would be best if they did not grant that permission to anyone, and that it would instead be prudent for them to do the initial connect server permission grant.

We also spoke about the option of them hosting one centralized connect server for all parties in the city vs. them doling out the credentials needed for various DTS-like groups in the city to stand up their own resources. I advocated for the latter because it sheds a ton of responsibility off them in terms of maintaining that, and also because it allows groups to size their connect server's resources based on their own needs. It seemed that there was a consensus around going with the latter option.

Bart then jumped right into getting us what we needed and he:

This is just exactly what we needed to move forward with setting up a test connect server, and I will ask in our planning meeting coming up everyone is good with me moving forward on this part of the work. Additionally, I committed to sending Bart a list of users who we would like added to this new vault, which I think should mirror our ACL for the current vault. We can talk about this in planning too.

In terms of a possible, future migration to the COA enterprise 1PW account, we discussed their ability to synchronize user lists for permissions to vaults with groups that are defined in the Office 365 federated service. I don't have a ton of familiarity with that system at this time, but I am hopeful that this will be a way for us to control our own user lists and permissions, which is a huge win once it's setup.

amenity commented 2 months ago

THANK YOU, Frank, for the fantastic work and documentation. 🙏🏻

dianamartin commented 2 months ago

[heart] Martin, Diana reacted to your message:

From: Frank Hereford @.> Sent: Tuesday, April 16, 2024 6:54:28 PM To: cityofaustin/atd-data-tech @.> Cc: Martin, Diana @.>; Mention @.> Subject: Re: [cityofaustin/atd-data-tech] Stand up test 1password connect server on enterprise 1pw (Issue #16372)

External Email - Exercise Caution

TLDR

We're good to move forward with setting up the connect server and everything is progressing as hoped.

Meeting Apr 16

We had a really great meeting today with Bart & Tarek from ISO. From our team, we had @maccallumphttps://github.com/maccallump , @chiaberryhttps://github.com/chiaberry , @amenityhttps://github.com/amenity and myself.

We introduced ourselves and caught up and discussed different ways of going about setting up the connect server in terms of user permissions. We all agreed that it would be best if they did not grant that permission to anyone, and that it would instead be prudent for them to do the initial connect server permission grant.

We also spoke about the option of them hosting one centralized connect server for all parties in the city vs. them doling out the credentials needed for various DTS-like groups in the city to stand up their own resources. I advocated for the latter because it sheds a ton of responsibility off them in terms of maintaining that, and also because it allows groups to size their connect server's resources based on their own needs. It seemed that there was a consensus around going with the latter option.

Bart then jumped right into getting us what we needed and he:

This is just exactly what we needed to move forward with setting up a test connect server, and I will ask in our planning meeting coming up everyone is good with me moving forward on this part of the work. Additionally, I committed to sending Bart a list of users who we would like added to this new vault, which I think should mirror our ACL for the current vault. We can talk about this in planning too.

In terms of a possible, future migration to the COA enterprise 1PW account, we discussed their ability to synchronize user lists for permissions to vaults with groups that are defined in the Office 365 federated service. I don't have a ton of familiarity with that system at this time, but I am hopeful that this will be a way for us to control our own user lists and permissions, which is a huge win once it's setup.

— Reply to this email directly, view it on GitHubhttps://github.com/cityofaustin/atd-data-tech/issues/16372#issuecomment-2059735902, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AFBCRD5OTYUHA7AAU4DD5S3Y5VXWJAVCNFSM6AAAAABFAHHZCGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANJZG4ZTKOJQGI. You are receiving this because you were mentioned.Message ID: @.***>

CAUTION: This is an EXTERNAL email. Please use caution when clicking links or opening attachments. If you believe this to be a malicious or phishing email, please report it using the "Report Message" button in Outlook. For any additional questions or concerns, contact CSIRT @.***"

frankhereford commented 2 months ago

Today, I've spent some time setting up the following in pursuit of a connect server serving secrets from the enterprise 1PW service:

And it worked! We have a connect server running the latest and greatest versions of the code with more sensible names than what the cloud formation template they publish provides. I've reused the security group for the developers and our city network, so it should be available to the same folks and services which have access to our existing, DTS provided connect service.

$ op read "op://[coa vault name]/Secret/password"                      
Shhh... this is my secret

At this point, I see no blockers, from a technical perspective, that prevent us from moving forward with a transition to the COA enterprise 1PW service. I think we do owe ourselves a conversation about our excitement level about giving up the end-all-be-all control over our secret storage, especially in light that it's become clear that the COA administrators of the enterprise service will (and have to, essentially) be able to access our secrets in our shared vaults, but that is solidly in the realm of policy and outside of verifying our technical ability.

frankhereford commented 2 months ago

A last thought -- I created a very barebones docker compose stack that can run a connect service on any of our on-prem machines if we want with no additional effort. We may consider this to eliminate a point-of-failure for short-lived communication disruptions between our on-prem machines and 1PW's centralized servers -- such as when there is a network disruption.