Is the plugin interface planned around the "emulated vault" experimental feature already in ATC? https://github.com/apache/trafficcontrol/tree/master/experimental/emulated_vault. The emulated vault shim layer looks quite clean and extensible. Also, just want to confirm that both the use cases of storing DS certs/keys and DNSSEC keys are planned to be covered. Thanks, -Amar
On 2020/12/16 18:03:53, Rawlin Peters <raw...@apache.org> wrote: > Thank you all for the feedback. It sounds like Postgres can do the > job, so I'll move forward with the blueprint for implementing it as a > type of plugin interface with Postgres and Riak as the two > implementations to begin with. If we wanted to add HashiCorp Vault (or > something else) as another plugin implementation later on, the plugin > interface should make that easier. > > - Rawlin > > On Mon, Dec 7, 2020 at 9:48 PM Chatterjee, Srijeet > <srijeet_chatter...@comcast.com.invalid> wrote: > > > > +1 on moving away from Riak and using postgres instead. Riak can be a > > pain(atleast for new users) to set up and debug. > > > > --Srijeet > > > > From: John Rushford <jjrushf...@gmail.com> > > Date: Monday, December 7, 2020 at 8:07 PM > > To: dev@trafficcontrol.apache.org <dev@trafficcontrol.apache.org> > > Subject: Re: [EXTERNAL] Re: Replace Riak w/ PostgreSQL > > +1 on using Postgres. I’ve played around with Postgres and pgcrypto. > > Keeping certs and sig keys encrypted is easily done in postgres. I used > > asymmetric public private key encryption with pgcrypto where I stored the > > public key to encrypt in a database table. The private key was stored > > apart from the database and used by an api that had secure access to the > > private key. This worked quite well and is mostly done with Postgres > > queries > > > > Sent from my iPhone > > > > > On Dec 7, 2020, at 4:00 PM, Gray, Jonathan > > > <jonathan_g...@comcast.com.invalid> wrote: > > > > > > HashiCorp Vault and/or Consul is the only other primary contender I > > > think we've had proposed, but I'm +1/+1 as well. > > > > > > Jonathan G > > > > > > On 12/7/20, 3:58 PM, "Rawlin Peters" <raw...@apache.org> wrote: > > > > > > Yes, I agree with the plugin interface as well, but that is what I was > > > hoping to defer to a follow-up thread, preferably with a rough draft > > > of a blueprint in hand. First, I just want to get an official > > > consensus on PostgreSQL (in this case as the _main_ plugin > > > implementation). > > > > > > - Rawlin > > > > > >> On Mon, Dec 7, 2020 at 2:24 PM Robert O Butts <r...@apache.org> wrote: > > >> > > >> +1 and +1 to what @neuman said. I'd vote this be framed more like "change > > >> TO secret store to a Plugin interface, and ATC will provide a Postgres > > >> Plugin." > > >> > > >> I'd also like to note, I believe our company has a legal requirement to > > >> have a separate "secret" database, so the Postgres secret store needs to > > >> at > > >> least have the ability to be a separate DB URL+auth than the primary TO > > >> Postgres DB. > > >> > > >> > > >>> On Mon, Dec 7, 2020 at 2:13 PM Dave Neuman <neu...@apache.org> wrote: > > >>> > > >>> I am +1 for using Postgres, however we should consider implementing the > > >>> "secret store" functionality in such a way that people can choose to > > >>> implement whatever backend they want. I think it can be accomplished > > >>> using > > >>> the TO plugin functionality but I am sure people more familiar with the > > >>> code these days would know better. This would also provide a built in > > >>> way > > >>> to migrate from one to the other without forcing everyone to change. > > >>> > > >>> > > >>> > > >>>> On Mon, Dec 7, 2020 at 1:48 PM Rawlin Peters <raw...@apache.org> wrote: > > >>> > > >>>> Hey folks, > > >>>> > > >>>> I hope by now everyone can agree that we need to replace Riak (it's > > >>>> been unmaintained for quite some time now). However, we might not all > > >>>> agree yet on what it should be replaced with (at least not > > >>>> officially). We've discussed it in threads here and there, but I'd > > >>>> like to get some official consensus before we really hit the ground > > >>>> running. > > >>>> > > >>>> I would like to propose that we replace Riak with PostgreSQL. > > >>>> > > >>>> Here are some of the reasons that I can think of (and have been > > >>>> mentioned by others in the past) for us to use PostgreSQL: > > >>>> - we all have much experience running it in production (because we > > >>>> already run it for the Traffic Ops database) > > >>>> - it would simplify ATC deployments by removing one more component > > >>>> from the system > > >>>> - it would simplify development as ATC devs are already familiar with > > >>>> traditional SQL databases, and we could reuse a lot of the existing > > >>>> code > > >>>> - it has a healthy community of support and doesn't seem to be losing > > >>>> steam anytime soon (it still remains the 2nd most popular OSS > > >>>> relational database behind MySQL [1]) > > >>>> > > >>>> I would like this thread to focus on the merits (or lack thereof) of > > >>>> using PostgreSQL as a replacement for Riak. We can discuss the > > >>>> low-level implementation details separately in the blueprint I will > > >>>> propose as a follow-up to this discussion. Unless someone is > > >>>> vehemently -1 on using PostgreSQL to replace Riak, I will take silence > > >>>> as assent and move forward with the blueprint process. > > >>>> > > >>>> - Rawlin > > >>>> > > >>>> [1] > > >>>> https://urldefense.com/v3/__https://db-engines.com/en/ranking_osvsc__;!!CQl3mcHX2A!Xy7f_5hSaPy1VOI6G3s7dnOKEWWmrpYJK1noQ67A3gTlldrSM596Zx4YjjbMHFUITPk4$<https://urldefense.com/v3/__https:/db-engines.com/en/ranking_osvsc__;!!CQl3mcHX2A!Xy7f_5hSaPy1VOI6G3s7dnOKEWWmrpYJK1noQ67A3gTlldrSM596Zx4YjjbMHFUITPk4$> > > >>>> > > >>> > > > >
