mirror of
https://github.com/supabase/supabase.git
synced 2026-10-12 12:55:06 +03:00
Adds today's posts
This commit is contained in:
Copple committed
1 parent
b75aa92372
commit
e3caee6fe5
2 files changed
+275
No files matched your search
@@ -0,0 +1,98 @@
|
||||
---
|
||||
title: 'One more thing'
|
||||
description: "Let's be honest, it's never just one more thing."
|
||||
author: paul_copplestone
|
||||
image: lw5-community-day/community_day_og.jpg
|
||||
thumb: lw5-community-day/community_day_og.jpg
|
||||
tags:
|
||||
- launch-week
|
||||
date: '2022-08-19'
|
||||
toc_depth: 2
|
||||
---
|
||||
|
||||
Let's be honest, it's never just one more thing.
|
||||
Here's six more things that you need to know this Launch Week.
|
||||
|
||||
## Supabase Vault: manage secrets and encrypted data in Postgres {#supabase-vault}
|
||||
|
||||
|
||||
|
||||
Today we're [pre-releasing Supabase Vault](/blog/supabase-vault), a Postgres extension for managing secrets and encryption inside your database.
|
||||
Vault is a thin usability-layer on top of [pgsodium](https://github.com/michelp/pgsodium).
|
||||
|
||||
Vault is not available on the Supabase platform yet. This release is intended to gather user-feedback.
|
||||
|
||||
[Read more](/blog/supabase-vault).
|
||||
|
||||
## Auth UI {#auth-ui}
|
||||
|
||||
|
||||
|
||||
Auth UI was previously released as a single `<Auth/>` component in the `[@supabase/ui](http://github.com/supabase/ui)` library.
|
||||
We recognized it was one of the most popular aspects of the library and developers were installing the library to use the Auth component alone.
|
||||
|
||||
From today, you can install it [from its own NPM package](https://github.com/supabase-community/auth-ui):
|
||||
|
||||
```bash
|
||||
npm install @supabase/auth-ui-react
|
||||
```
|
||||
|
||||
We've decoupled this library from our own styling system and you are now able to (_deep breathe.._): create your own theme, use a pre-existing Supabase theme, extend a theme using token variables, create multiple variations of themes (and then also extend them with variables), use CSS classes and also use any inline CSS styles.
|
||||
|
||||
This is all done with [stitches.js](stitches.dev) (or more specifically, the [framework agnostic API](https://stitches.dev/docs/framework-agnostic)) to handle variants of components and the CSS properties.
|
||||
|
||||
A new feature in Auth UI is custom labels. You can now override any of the text labels - very useful for multiple language support.
|
||||
|
||||
Our initial release supports React, but we have prepared the repo for other frameworks. This release is a small step towards a larger feature - “_Hosted Auth Pages_”. The wide range of customization will become useful for developers to tweak their Hosted Auth pages to reflect their brand personality.
|
||||
|
||||
Read more.
|
||||
|
||||
---
|
||||
|
||||
## Dashboard permissions {#dashboard-permissions}
|
||||
|
||||
|
||||
|
||||
We've released granular permissions on our Supabase dashboard. Dashboard permissions allow you assign roles to your team and to restrict what they can do.
|
||||
|
||||
We're starting with 3 roles - Owner, Administrator and Developer - which you can edit in the Org settings of the Dashboard.
|
||||
There's a tooltip in the header of the members table, which will elaborate more on the individual permissions available for each role.
|
||||
|
||||
[Read more](/blog).
|
||||
|
||||
---
|
||||
|
||||
## New Postgres extension for JSON schema validation {#pg-jsonschema}
|
||||
|
||||
|
||||
|
||||
We've released a [new Postgres extension](/blog) on the Supabase platform today, [`pg_jsonschema`](https://github.com/supabase/pg_jsonschema).
|
||||
|
||||
`pg_jsonschema` adds support for [JSON Schema](https://json-schema.org/) validation for `json` and `jsonb` data types, built with Rust.
|
||||
You can read the [full blog post](/blog), which explains some of the scenarios where this is useful.
|
||||
|
||||
[Read more](/blog).
|
||||
|
||||
---
|
||||
|
||||
## Multi-Factor Authentication: Early Access {#mfa}
|
||||
|
||||
|
||||
|
||||
We've opened early-access signups for Multi-Factor Authentication (MFA). To be clear - this is for MFA for [Supabase Auth](/auth),
|
||||
which you can use to build additional layers of security in your applications (and not MFA for our Dashboard, which we will also release soon).
|
||||
|
||||
If you're interested, sign up so and we'll grant your projects early access to the MFA API endpoints.
|
||||
|
||||
[Sign up](/blog).
|
||||
|
||||
## pg_graphql v0.4.0 {#pg_graphql}
|
||||
|
||||
|
||||
|
||||
We've released a new version of `pg_graphql`, our GraphQL extension for Postgres.
|
||||
This release adds support for `json` / `jsonb` types, the `in` filter, and introspection for much larder schemas (10x larger than before). We've fixed a few bugs too.
|
||||
|
||||
You can read the [release notes](https://github.com/supabase/pg_graphql/releases/tag/v0.4.0) on and [documentation](https://supabase.github.io/pg_graphql/) GitHub, and start using `pg_graphql` on Supabase today.
|
||||
|
||||
[Read more](/blog/graphql-now-available).
|
||||
@@ -0,0 +1,177 @@
|
||||
---
|
||||
title: 'Supabase Vault'
|
||||
description: ''
|
||||
author: paul_copplestone
|
||||
image: lw5-community-day/community_day_og.jpg
|
||||
thumb: lw5-community-day/community_day_og.jpg
|
||||
tags:
|
||||
- launch-week
|
||||
date: '2022-08-19'
|
||||
toc_depth: 2
|
||||
---
|
||||
|
||||
Today we're pre-releasing [Supabase Vault](https://github.com/supabase/vault), a Postgres extension for managing secrets and encryption directly inside your database.
|
||||
Vault is a thin usability-layer on top of [pgsodium](https://github.com/michelp/pgsodium).
|
||||
|
||||
Vault is not available on the Supabase platform yet as we finalize usability and security testing.
|
||||
This release is intended to gather user-feedback from our community and customers.
|
||||
The SQL code for the vault itself is relatively simply, so if you want to live on the edge a bit all the Vault requires is the pgosdium extension.
|
||||
|
||||
Soon we will be releasing a blog post that describes more of the technology in [libsodium](https://doc.libsodium.org/) and
|
||||
[pgsodium](https://doc.libsodium.org/) that's behind the Vault. For now, we will go through a quick example of storing a secret, like a service access token, into the Vault.
|
||||
|
||||
## Background
|
||||
|
||||
Until now, the industry-standard for PostgreSQL encryption is a built-in extension called [`pgcrypto`](https://www.postgresql.org/docs/current/pgcrypto.html).
|
||||
Like most cloud providers, Supabase offers `pgcrypto` for developers to use in their applications. `pgcrypto` has been around for a long time,
|
||||
and while it supports some basic encryption and decryption abilities, it lacks features like public key signing, key derivation APIs, streaming encryption, and other modern features required by advanced security-first applications.
|
||||
|
||||
### Problems with pgcrypto
|
||||
|
||||
Databases often store sensitive information, and they need tools that guarantee this data is stored and backed-up in an encrypted form.
|
||||
A fundamental issue with `pgcrypto` is that it lacks the ability to derive keys from outside of SQL. Instead you must have the raw encryption key for the algorithm you wish to use:
|
||||
|
||||
```sql
|
||||
create extension pgcrypto;
|
||||
|
||||
create table users (
|
||||
id serial primary key,
|
||||
email varchar not null unique
|
||||
);
|
||||
|
||||
insert into users (email) values
|
||||
(pgp_sym_encrypt('alice@supabase.io', 's3kr3t_k3y')),
|
||||
(pgp_sym_encrypt('bob@supabase.io', 's3kr3t_key'));
|
||||
```
|
||||
|
||||
`pgcrypto` works with _raw_ keys. In order to encrypt the data with pgcrypto you must pass the key directly to the encryption function.
|
||||
Leaking those raw keys is all too easy - logs, files, clients, tables, replication streams - you name it.
|
||||
Wouldn't it be great if you could encrypt data, but instead of specifying the raw key, you specify some indirect way, like with a key ID?
|
||||
|
||||
## Supabase Vault
|
||||
|
||||
We've created a [new PostgreSQL extension](https://github.com/supabase/vault) called `vault`.
|
||||
The Vault is a good place to put things like API keys, access tokens, and other secrets from external services that you use in your application.
|
||||
The core of the Supabase Vault is a table with some metadata and an encrypted text column where you can put your secrets and any metadata related to them.
|
||||
|
||||
We take the pain out of key management by pre-generating a unique, per-database Key ID that is used by default - a “root” key - which is stored outside of the SQL language,
|
||||
accessibly only internally in the Postgres server by the libsodium library. This root key is managed by the [pgsodium](https://github.com/michelp/pgsodium) Postgres extension
|
||||
when the server boots using [Server Key Management.](https://github.com/michelp/pgsodium#server-key-management)
|
||||
|
||||
pgsodium provides an Encryption and Key Derivation API based on the [libsodium library](https://libsodium.gitbook.io/doc/) and can get it's root key from a
|
||||
variety of source depending on how you configure it. Supabase generates and preserves your project's root key behind the scenes, so you don't have to worry about it.
|
||||
If you install pgsodium locally the default is to generate a random root key from the `/dev/urandom` device which is then saved in a file in your Postgres data directory.
|
||||
|
||||
To get started, install the `vault` extension:
|
||||
|
||||
```sql
|
||||
create extension vault with schema vault;
|
||||
```
|
||||
|
||||
Once enabled, you can start inserting secrets into the `vault.secrets` table immediately:
|
||||
|
||||
```sql
|
||||
insert into vault.secrets (secret, associated)
|
||||
values ('s3kr3t_k3y', 'This is the secret API service key.');
|
||||
```
|
||||
|
||||
Now when you look in the `vault.secrets` table, the secret is encrypted:
|
||||
|
||||
```sql
|
||||
> select * from vault.secrets;
|
||||
-[ RECORD 1 ]--------------------------------------------------------
|
||||
id | f6a2fe0a-3471-4eea-a581-75c4d2be396b
|
||||
secret | /eT9bb96POTJ7L2gYrluTZ3r3pG5IMwPSQo6pQP0xdZTarpRrpWPXTWQ
|
||||
key_id | caabfc28-2ab3-48f5-8978-1b3d4b659911
|
||||
associated | This is the secret API service key.
|
||||
nonce | \x77c7381c523630ba72f1f137626a9f9a
|
||||
created_at | 2022-08-18 19:33:15.312651+00
|
||||
```
|
||||
|
||||
Notice how the row has a `key_id` column. This is the _ID_ of the internally derived key that is used to encrypt the secret, not the key itself.
|
||||
The actual raw key is not available to you in SQL, it is managed entirely outside of the SQL language in the Postgres server.
|
||||
pgsodium [supports a variety of ways](https://github.com/michelp/pgsodium#server-key-management) to place the root key into Postgres.
|
||||
At Supabase, we manage this key for your project automatically and generate a unique default Key ID for you in the `secrets` table.
|
||||
|
||||
To see the decrypted data, there is a special view created called `vault.decrypted_secrets`:
|
||||
|
||||
```sql
|
||||
select * from vault.decrypted_secrets;
|
||||
```
|
||||
|
||||
<small>Result</small>
|
||||
|
||||
```
|
||||
-[ RECORD 1 ]----+---------------------------------------------------------
|
||||
id | f6a2fe0a-3471-4eea-a581-75c4d2be396b
|
||||
secret | /eT9bb96POTJ7L2gYrluTZ3r3pG5IMwPSQo6pQP0xdZTarpRrpWPXTWQ
|
||||
decrypted_secret | s3kr3t_k3y
|
||||
key_id | caabfc28-2ab3-48f5-8978-1b3d4b659911
|
||||
associated | This is the secret API service key.
|
||||
nonce | \x77c7381c523630ba72f1f137626a9f9a
|
||||
created_at | 2022-08-18 19:33:15.312651+00
|
||||
```
|
||||
|
||||
Now you can see that there is a new `decrypted_secret` column that contains the decrypted secret that was originally inserted into the table.
|
||||
This `vault.decrypted_secrets` view automatically decrypts rows in the `vault.secrets` table “on-the-fly” as you query them, but the secret is stored on disk in _encrypted_ form.
|
||||
If you take a backup, or pause your project, that data remains encrypted. We will keep your hidden root key safe in our backend systems for when you need to restore or un-pause your projects.
|
||||
|
||||
If you wish to use different key ids for different secrets, you can create new keys with the `pgsodium.create_key()` function:
|
||||
|
||||
```sql
|
||||
select * from pgsodium.create_key('API_KEY_DEV');
|
||||
```
|
||||
|
||||
<small>Result</small>
|
||||
|
||||
```
|
||||
-[ RECORD 1 ]-------------------------------------
|
||||
id | f9f176eb-7069-4743-9403-582c04354ffc
|
||||
status | valid
|
||||
created | 2022-08-18 22:31:50.331792
|
||||
expires |
|
||||
key_type | aead-det
|
||||
key_id | 2
|
||||
key_context | \x7067736f6469756d
|
||||
comment | This is the comment for the new key
|
||||
user_data |
|
||||
```
|
||||
|
||||
Now you can encrypt table secrets with this new key by inserting its ID explicitly:
|
||||
|
||||
```sql
|
||||
insert into vault.secrets (secret, associated, key_id)
|
||||
values (
|
||||
'apikey_XaYrurzcquqhEdBjzfTzfwAZqpd',
|
||||
'API_KEY_DEV',
|
||||
'f9f176eb-7069-4743-9403-582c04354ffc'
|
||||
)
|
||||
returning *;
|
||||
```
|
||||
|
||||
<small>Result</small>
|
||||
|
||||
```
|
||||
-[ RECORD 1 ]------------------------------------------------------------
|
||||
id | 9c58a0f3-aa40-4789-b683-6db48b241f9e
|
||||
secret | YWxuTnWdF55MuRrZ7xneBvaz2uH59U1dJV/7CCZjSn5B5jELOoy/csq8x/s=
|
||||
key_id | f9f176eb-7069-4743-9403-582c04354ffc
|
||||
associated | This is some different associated data.
|
||||
nonce | \xd39808b07c9ae52c8f02c33a7f87595c
|
||||
created_at | 2022-08-18 22:34:07.219941+00
|
||||
```
|
||||
|
||||
The type of encryption used by the Vault is called [Authenticated Encryption with Associated Data](https://en.wikipedia.org/wiki/Authenticated_encryption).
|
||||
The data you insert into the `associated` column is combined with the encrypted text when libsodium creates the authentication signature for the secret.
|
||||
This means that when you read the secret, you know that the associated data is also authentic. This would be a good place to put account IDs or other
|
||||
data that ties your system to the secret. And as always, you can refer to rows in the secrets table by their primary key UUID.
|
||||
|
||||
If you only want to store secrets that you know are encrypted on disk and in backups, then all you need to know is shown above. Just insert secrets into the table,
|
||||
optionally creating new keys depending on your purposes, and select them from the view when you want to use them.
|
||||
|
||||
## Going Beyond the Vault
|
||||
|
||||
The Vault is good for a reasonable amount of secure data, like API keys for services, access tokens or environment variables,
|
||||
but if you have a lot more sensitive information, like personally Identifiable Information (PII) that you want to relate to your overall model,
|
||||
you may want to break them out into side tables that uses pgsodium's
|
||||
[Transparent Column Encryption](https://github.com/michelp/pgsodium#transparent-column-encryption) which we will describe soon in a follow-up blog post. Stay tuned!
|
||||
Reference in new issue
Block a user