Add table encryption support?

Bug #1921861 reported by Sebastian Gumprich
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack-Ansible
Fix Released
Undecided
Unassigned

Bug Description

I need to add encryption support[0] to my databases. For this I added some code that's working fine for me. Please see the attached patch.

Do you want to get this included (I don't want to maintain a fork)? If yes, what are the required steps?

[0]: https://mariadb.com/kb/en/data-at-rest-encryption-overview/#which-storage-engines-does-mariadb-encryption-support

Revision history for this message
Sebastian Gumprich (amcs-segu) wrote :
Revision history for this message
Sebastian Gumprich (amcs-segu) wrote :

To add: There is some missing code to remove the plaintext password files. However I wanted to get this out first and see if interest is there for this feature.

Revision history for this message
Dmitriy Rabotyagov (noonedeadpunk) wrote :

Hi Sebastian,

Thanks for reaching us!

Generally feature looks interesting. There are some concerns about the usecase, because with file implementation encrypton keys are stored on the same place as database which does not feel like secure. So I guess implementing option to select encryption plugin and install it (like aws_key_management) would be also cool.

Also there are some comments regarding current patch, since in case of the cluster, you probably need to generate them on localhost and later distribute to galera containers/hosts.

But yes, I'd say we have nothing against implementing this feature, and you may go ahead and push patch for it. For this you will need to setup a gerrit account https://docs.openstack.org/contributors/common/setup-gerrit.html after which you can make a commit and run `git review` to push it.

Changed in openstack-ansible:
status: New → Triaged
Revision history for this message
Sebastian Gumprich (amcs-segu) wrote :

Thanks for your answer, Dmitriy!

> There are some concerns about the usecase, because with file implementation encrypton keys are stored on the same place as database which does not feel like secure.

Yes, that is a problem. The keys are only needed on startup of the mysql instances and can afterwards be deleted. This however can be a operational problem since you have to provide the keys on startup, which is then not automatic, anymore.

Right now I think the best idea is to put the keys on the server with Ansible, startup the instance, then delete the keys. What do you think?

> So I guess implementing option to select encryption plugin and install it (like aws_key_management) would be also cool.

I have no possibility to test this with AWS or eperi, however I can provide some initial code and if some other person needs it, it can be further developed.

> Also there are some comments regarding current patch, since in case of the cluster, you probably need to generate them on localhost and later distribute to galera containers/hosts.

Good idea! I'll add that.

> But yes, I'd say we have nothing against implementing this feature, and you may go ahead and push patch for it.

Thanks, will do!

Revision history for this message
Dmitriy Rabotyagov (noonedeadpunk) wrote :

> Right now I think the best idea is to put the keys on the server with Ansible, startup the instance, then delete the keys. What do you think?

Will that mean service restart will fail without keys being in place? If they're required only during initial startup, than this might be good idea to remove them afterwards. And we probably would need to avoid their deployment as well during following runs. This can be probably done with ansible local facts. We already have galera_deployed that can be leveraged

> I have no possibility to test this with AWS or eperi, however I can provide some initial code and if some other person needs it, it can be further developed.

Yeah, that's what I meant - let's make an option to choose driver at least config wise, and interested ppl may iterate later.

Revision history for this message
Dmitriy Rabotyagov (noonedeadpunk) wrote :

Also you can join us on Freenode IRC in #openstack-ansible channel if you want.

Changed in openstack-ansible:
status: Triaged → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to openstack-ansible-galera_server (master)

Reviewed: https://review.opendev.org/c/openstack/openstack-ansible-galera_server/+/784069
Committed: https://opendev.org/openstack/openstack-ansible-galera_server/commit/e91c8be4492aee2327911ddea5b7decede388af9
Submitter: "Zuul (22348)"
Branch: master

commit e91c8be4492aee2327911ddea5b7decede388af9
Author: Sebastian Gumprich <email address hidden>
Date: Wed Mar 31 12:32:37 2021 +0200

    add support for encryption

    Closes-Bug: #1921861

    Change-Id: I73e548ac208a96ddaa687a1b5fbb22cac20037d0

Changed in openstack-ansible:
status: In Progress → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/openstack-ansible-galera_server yoga-eom

This issue was fixed in the openstack/openstack-ansible-galera_server yoga-eom release.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/openstack-ansible-galera_server wallaby-eom

This issue was fixed in the openstack/openstack-ansible-galera_server wallaby-eom release.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/openstack-ansible-galera_server xena-eom

This issue was fixed in the openstack/openstack-ansible-galera_server xena-eom release.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.