Since we have an automation framework in place, we should add creating a project to sentry in the list of things that creating an Imbi project does. The automation should do the following:
add the organizational_slug and authorization token to the configuration file
use the namespace slug as the team_slug, add a sentry_team_slug column to v1.namespaces so that the slug can be overridden (don't forget the admin UI components)
create a new project using the project name and slug as the name and slug parameters
generate a new client key and store the public and secret values somewhere (see below)
I introduced a keychain abstraction a little while ago. We should create a new table that holds project secrets keyed by a unique and free-form identifier. Something like:
CREATE TABLE IF NOT EXISTS v1.project_secrets (
project_id INTEGER NOT NULL,
secret_name TEXT NOT NULL,
secret_value TEXT NOT NULL,
created_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT CURRENT_TIMESTAMP,
created_by TEXT NOT NULL,
last_modified_at TIMESTAMP WITH TIME ZONE,
last_modified_by TEXT,
PRIMARY KEY (project_id, secret_name),
FOREIGN KEY (project_id) REFERENCES projects (id) ON UPDATE CASCADE ON DELETE CASCADE
);
The secret_value would be the binary (or Base64-encoded) keychain encrypted value of the secret. This would let us generate K8S secrets, load values into Vault or whatever in the future.
Since we have an automation framework in place, we should add creating a project to sentry in the list of things that creating an Imbi project does. The automation should do the following:
organizational_slug
and authorization token to the configuration fileteam_slug
, add asentry_team_slug
column tov1.namespaces
so that the slug can be overridden (don't forget the admin UI components)name
andslug
parameterspublic
andsecret
values somewhere (see below)API References
Key storage
I introduced a keychain abstraction a little while ago. We should create a new table that holds project secrets keyed by a unique and free-form identifier. Something like:
The
secret_value
would be the binary (or Base64-encoded) keychain encrypted value of the secret. This would let us generate K8S secrets, load values into Vault or whatever in the future.