Encryption at rest

Using FoundationDB Kubernetes Operator
1

How would I set that in the CRDs, is there a way to either manually run the configure new command or someway to pass options that aren’t yet supported?

Thanks!

2

How would I set that in the CRDs, is there a way to either manually run the configure new command or someway to pass options that aren’t yet supported?

We don’t have a way to pass down configuration options that are not supported. We could probably extend the DatabaseConfiguration struct to take some additional configuration arguments that are not checked, which could be used to test new options that are not yet implemented in the operator. Feel free to open an issue in the operator repository and we can see how to implement that feature (happy to review a PR if you want to work on this).

You can configure your database manually by setting configureDatabase to false (see: https://github.com/FoundationDB/fdb-kubernetes-operator/blob/main/docs/cluster_spec.md#foundationdbclusterautomationoptions) I would recommend to let thee operator do the initial configuration and after that you can run your manual configuration command. You have to set this option to false to ensure the operator is not overwritting your manual changes (since the configuration would be different from the desired one). Just keep in mind that the operator won’t do any configuration changes in this case e.g. all/most changes to the DatabaseConfiguration will be ignored.

edit I have to correct myself: If the configuration option is unknown to the operator it will be ignored, even if the value is set (or not). So running the according configure command manually should be enough.

Docs for running commands in the FDB cluster: https://github.com/FoundationDB/fdb-kubernetes-operator/blob/main/docs/manual/debugging.md#running-cli-commands

3

As a reference here is the code where we generate the configuration string fdb-kubernetes-operator/foundationdb_database_configuration.go at main · FoundationDB/fdb-kubernetes-operator · GitHub appending an unchecked set of arguments for testing should be fairly easy to implement.

4

Thanks for the help, I haven’t written an operator or messed with one, but ill try my hand. Worst case scenario I can use the don’t configure option. Out of curiosity, how does

I would recommend to let thee operator do the initial configuration and after that you can run your manual configuration command

Play out, do I create the cluster with configureDatabase as false, do the initialization myself, then update it to true?

5

The easiest way to enable the encryption setup is by doing it manually via a configure command on the running cluster.

Play out, do I create the cluster with configureDatabase as false, do the initialization myself, then update it to true

Actually it’s the other way create the cluster without defining configureDatabase or set to true after the cluster is created and reconciled you can set configureDatabase to false and do some configuration changes.

But like I mentioned above: If the configuration option is unknown to the operator it will be ignored, even if the value is set (or not). So running the according configure command manually should be enough. So just running the configure command manually should be enough to enable encryption at rest.

6

Just wonder if it is ok to first set the configureDatabase to false, run the configure command like “configure new ssd encryption_at_rest_mode=aes_256_crt” and then turn the configureDatabase back to true. The purpose is to minimize parsing the user defined Clusterfile so that we enabled the encryption but let the operator to set the other configuration like redundancy mode, # of process etc. Would that work. Or if we opt to run the configure manually, then we are also responsible for the other configuration as well?

7

I haven’t tested this and I’m not to familiar with the encryption_at_rest_mode configuration but the following steps should work:

  • Create cluster and wait that the cluster is reconciled.
  • Exec into a Pod and run the configure encryption_at_rest_mode=aes_256_crt command (I’m not sure if you really need to specify the ssd).

That should work without any issues but I would encourage you to test it once in a small cluster. Otherwise you can also extend the operator to manage this additional configuration setting.

1 Like
8

I think the main thing is to set the configureDatabase to false?
IF a database has been created, can’t change the encryption_at_rest mode.

1 Like
9

I think the main thing is to set the configureDatabase to false?
IF a database has been created, can’t change the encryption_at_rest mode.

You don’t have to set the configureDatabase to false (see the edit comment: Encryption at rest - #2 by johscheuer). So you can leave the configureDatabase setting true and just run the configure command to enable the encryption_at_rest_mode once manually. The operator is not aware of this configuration and there shouldn’t make any changes.

As always: I suggest to test this in a small dev cluster.

1 Like