Re: Regd. the Implementation of Wallet (in Oracle) config equivalent in postgreSQL whilst the database migration

[Rainer Duffner]

> Am 22.12.2022 um 10:46 schrieb Peter J. Holzer :
> 
> If the hacker has root access: What prevents them from talking to the
> HSM?


I wasn’t involved in setting it up here, but AFAIK you need to „enroll“ the 
client to the HSM.

That is a one-time process that requires HSM credentials (via certificates and 
pass-phrases).

Then, that client can talk to the HSM. 

The HSM-client is (or should be) engineered in such a way that you can’t 
extract the encryption-secret easily.

I am not sure, but IIRC, you should not even be able to clone the VM without 
the HSM noticing or the clone not working at all to begin with (for lack of 
enrollment). Though most production databases are too large to just „clone“.

Maybe someone who knows more about this subject can chime in before I make a 
fool of myself?
;-)




Rainer

Re: Regd. the Implementation of Wallet (in Oracle) config equivalent in postgreSQL whilst the database migration

[Rainer Duffner]

> Am 22.12.2022 um 00:57 schrieb Benedict Holland 
> :
> 
> Like, does oracle give you something more? Probably. It's also a ton of money 
> and I mean a geuine ton. At that point, you also need security audits, 
> security protocols, requirements, backup and retention policies, and 
> redundancy key locations. If someone has root, I don't know how they also 
> don't have your encryption keys. 

They are not on the same box. They are in a HSM. A dedicated piece of 
tamper-proof hardware that stores secrets (keys).
The Oracle-server needs to talk to the HSM to get the keys. 

This is not a low-budget setup (well, it’s Oracle…) - rather, it’s for when the 
data is really very valuable so that the cost for redundant HSMs, Oracle, Data 
Guard etc.pp. is still lower than the value of the data. 

OP works for an outfit that typically does outsourcing for these kinds of 
clients.

It’s all about having more degrees of separation between different functions, 
so you don’t have to trust the single, Dennis-Nedry-type of admin to not sell 
the information in the database to the highest bidder.

Re: Regd. the Implementation of Wallet (in Oracle) config equivalent in postgreSQL whilst the database migration

[Rainer Duffner]

> Am 21.12.2022 um 22:34 schrieb Laurenz Albe :
> 
> There is no exact equivalent, but there is something similar and much better: 
> you can
> authenticate the client with SSL client certificates:
> https://www.postgresql.org/docs/current/auth-cert.html 
> 

Isn’t the wallet the part where the encryption keys are stored?

Indeed, one of the few remaining features that only Oracle (and of course other 
commercial RDMSs) has seems to be full HSM support for TDE.


Rainer

Re: Postgresql + containerization possible use case

[Rainer Duffner]

> Am 13.12.2021 um 12:41 schrieb Achilleas Mantzios 
> :
> 
> Our setup has been open source since forever. So licenses for something that 
> used to be free for ages would be hard to introduce.


That ist totally understandable.
140x800 for the RHEL license alone is over 100k/year.
Though you might get a volume discount at that point ;-)


> So Docker is NOT free? Please share your thoughts? I am a complete noob. 


The commercial version is not free.
The „CE“ version is free, but I’m not sure how stable the API is.

Dockerhub, for what it’s worth, isn’t completely free anymore either.



> Those servers I am talking about have no internet connectivity. And the 
> satellite connection costs are high.
> (although I think we pay a fixed amount for a certain total data transfer 
> size).
> 


Yes. That’s why using a more offline-friendly infrastructure might make more 
sense.

RHEL seems to be pretty well tuned running in high-secure air-gapped networks - 
which is what a ship basically is.

>> The question is: do you want to get there?
>> But maybe your developers want to get here, because they don’t want to learn 
>> about software-packaging (anymore) - but is that what the business wants?
>> 
> Those servers live for years, the objective is to facilitate upgrades. 


Yes, but docker-upgrades aren’t free either.

At least, I cannot imagine running such an infrastructure in the gung-ho style 
that a typical developer runs his docker-containers.

You’d want to run a tight ship with those ;-)

You will need a lot more tooling around this (continuous integration, 
continuous deployment) - which is the reason I suggested moving all this 
infrastructure to the ship itself. If you produce and mirror the artifacts 
locally, you should have less backhaul traffic (which is what I assume is 
killing you with sat-com - downstream can probably be had cheap-ish these days 
- or pretty soon via the likes of StarLink)





>> 
>> https://www.docker.com/blog/how-carnival-creates-customized-guest-experiences-with-docker/
>>  
>> Thanks
>>  for the link, I didn't quite understand what they do with docker (video 
>> included).

It’s passenger entertainment and engagement, from what I can see.

It’s sad and funny to read, as shortly after that huge cruises got out of 
fashion ;-)


It’s also not mission-critical.



> 120 docker containers in two data centers on the ship? Ours will be just a 
> single linux box with limited connectivity (in some seas no connectivity ) to 
> the internet/shore.


Yes, and this is IMO where you will have to get management on board to upgrade 
infrastructure and tooling around docker containers (and likely Kubernetes) - 
if your developers persist on using it that way.

You will end up running a small server-cluster on each ship - I would guess 
there are specialized vendors who produce sea-worthy server-equipment.



>> 
>> (That was pre-pandemic…)
>> 
>> I would make an educated guess that you’d need to have the whole 
>> docker-infrastructure on each ship (build-server, repository etc.pp.) to 
>> minimize sat-com traffic.
> 
> Hmm, I don't know about that. The hardware is given (existing) and limited.
> You are like the 2nd person who warned about comms as being an issue with 
> docker/containers.
> 
> Can't someone have a free docker system inside a linux server and run the 
> containers (free again) until he/she decides to upgrade either docker or 
> (more frequently) one of the images?
> Is Docker upwards compatible? Meaning new Docker versions to run old images ?


Yes, likely. But upgrading docker itself sometimes comes with its own 
challenges.

As you said, all these servers are with limited connectivity and no local help 
available...

Again, I’m the last person you want to ask how docker actually works (but 
often, the developers themselves don’t know either, but they know which 
commands to feed it…)

Also, most of my knowledge of ships is from watching NCIS (and reading Clive 
Cussler novels...). 


> 
>> 
>> I mean, it looks like it could be done. But this is where the „dev“ part in 
>> the „devops" world has to take a step back and the „ops“ guys need to come 
>> forward.
>> 
> Can you please explain in more detail?


With 140-ish servers air-gapped on vessels around the world, this is IMO a 
serious operations-problem and needs to be handled properly, with an air-tight 
(or water-tight…) operational concept.

Your infrastructure has outgrown its original design limits. Time to talk to 
management about upping the game (and the budget).




Best Regards

Re: Postgresql + containerization possible use case

[Rainer Duffner]

> Am 10.12.2021 um 13:01 schrieb Achilleas Mantzios 
> :
> 
> On 10/12/21 1:24 μ.μ., o1bigtenor wrote:
>> 
>> 
>> On Fri, Dec 10, 2021 at 3:24 AM Achilleas Mantzios 
>> mailto:ach...@matrix.gatewaynet.com>> wrote:
>> Hi
>> we are running some 140 remote servers (in the 7 seas via satellite 
>> connections), and in each one of them we run:
>> - jboss
>> - postgresql
>> - uucp (not as a daemon)
>> - gpsd
>> - samba
>> - and possibly some other services
>> 
>> Hardware and software upgrades are very hard since there is no physical 
>> access to those servers by trained personnel, and also there is a diversity 
>> of software versions.
>> 
>> The idea for future upgrades is to containerize certain aspects of the 
>> software. The questions are (I am not skilled in docker, only minimal 
>> contact with lxd) :
>> - is this a valid use case for containerization?
>> - are there any gotchas around postgersql, the reliability of the system ?
>> - since we are talking about 4+ basic services (pgsqk, jboss, uucp, samba), 
>> is docker a good fit or should we be looking into lxd as well?
>> - are there any success stories of other after following a similar path?
>> 
>> 
> Thanks
>> My experience with LXD is that upon install you are now on a regular update 
>> plan that is impossible to change. 
> Ehhmmm we are running some old versions there already (jboss, pgsql), LXD 
> would not differ in this regard.
> What do you mean? that the updates for LXD are huge? short spaced/very 
> regular?
> Can you pls elaborate some more on that?


IIRC, you can’t really control, which updates are installed for LXD (and snap). 
You can’t create a local mirror.

IIRC, you can delay snap updates, but you can’t really reject them. 

Maybe you can these days, with landscape server?

(insert the usual rant about Enterprise != Ubuntu here)

I don’t know about LXD, but as it’s only running on Ubuntu and is  apparently 
developed by a single guy (who might or might not work for Canonical - sorry, 
too lazy to check), I wouldn’t hold my breath as to its long-term viability.

Ubuntu will probably morph into a container-only, cloud-only OS sooner than 
later - the writing is on the wall (IMHO).


>> This means that your very expensive data connection will be preempted for 
>> updates at the whim of the 
>> canonical crew. Suggest not using such (most using such on wireless 
>> connections seem to have found 
>> the resultant issues less than wonderful - - cost (on the data connection) 
>> being #1 and the inability to achieve 
>> solid reliability crowding it for #2). 
> Crew has their own paid service. Business connection is for business not crew.


The word „crew“ was meant to say „employees of Canonical“ - I’m sure the 
allegory was not meant to mess with you...


> What I am interested is, could docker be of any use in the above scenario? 
> Containerization in general?
> The guys (admins/mgmt) here seem to be dead set on docker, but I have to 
> guarantee some basic data safety requirements.
> 


I know very little about docker, but IMO, for ultimate stability, you could 
switch to RHEL and use their certified images:

https://catalog.redhat.com/software/containers/search?q=PostgreSQL%2012&p=1


My coworker says, he re-packages all his docker-images himself (with RPMs from 
his own mirror), so that he understands what’s really in them.


The big problem that I see with your use-case and docker is that docker implies 
frequent, small updates to the whole stack - including docker itself (unless 
you pay for the LTS version).

This is not what you do right now, I reckon?

The question is: do you want to get there?
But maybe your developers want to get here, because they don’t want to learn 
about software-packaging (anymore) - but is that what the business wants?


https://www.docker.com/blog/how-carnival-creates-customized-guest-experiences-with-docker/

(That was pre-pandemic…)

I would make an educated guess that you’d need to have the whole 
docker-infrastructure on each ship (build-server, repository etc.pp.) to 
minimize sat-com traffic.

I mean, it looks like it could be done. But this is where the „dev“ part in the 
„devops" world has to take a step back and the „ops“ guys need to come forward.




Rainer