Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Persistence documentation page includes a mention of the deprecated Redis storage backend #1390

Closed
SanchithHegde opened this issue May 10, 2024 · 2 comments · Fixed by #1391

Comments

@SanchithHegde
Copy link
Contributor

Page: https://www.pomerium.com/docs/internals/data-storage#backends

Relevant line in the documentation source:

Pomerium encrypts record values only for the Redis storage backend (not for the in-memory or Postgres storage backends). When using the Postgres backend we recommend that users configure their own encryption at rest, for example by using full-disk encryption on the volume where Postgres data is stored.

What's incorrect or missing

The Redis storage backend was deprecated in the v0.24.0 release and the relevant parts of the documentation were removed in #1052, but there's still one more mention of it in the "Persistence" documentation page:

Pomerium encrypts record values only for the Redis storage backend (not for the in-memory or Postgres storage backends). [...]

I believe this would have to be removed or updated, as the maintainers see fit.

What's the resolution?

I think it can be updated to remove only the parts about Redis, something like:

Pomerium does not encrypt record values for either the in-memory or Postgres storage backends.

The updated paragraph would then look like:

Pomerium does not encrypt record values for either the in-memory or Postgres storage backends. When using the Postgres backend we recommend that users configure their own encryption at rest, for example by using full-disk encryption on the volume where Postgres data is stored.

Let me know if something would have to be updated here, and if you'd like me to open a PR.

@kenjenkins
Copy link
Contributor

Thanks for reporting! Yes, if you're willing to open a PR we'd be happy to review it.

@SanchithHegde
Copy link
Contributor Author

Thanks for reporting! Yes, if you're willing to open a PR we'd be happy to review it.

Sure, I've just opened PR #1391 to address this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants