Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

feat: add schema for key rotation#14662

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
sreya merged 13 commits intomainfromjon/keyschema
Sep 17, 2024
Merged

feat: add schema for key rotation#14662

sreya merged 13 commits intomainfromjon/keyschema
Sep 17, 2024

Conversation

@sreya
Copy link
Collaborator

@sreyasreya commentedSep 13, 2024
edited
Loading

This is the first delivery for an implementation for rotating our internal keys. This is mainly just schema related work. I opted forcrypto_keys instead ofkeys since it felt a little too generic and we already have existing key types (such asapi_keys).

Relates tocoder/internal#52

}

func (q*querier)DeleteCryptoKey(ctx context.Context,arg database.DeleteCryptoKeyParams) (database.CryptoKey,error) {
iferr:=q.authorizeContext(ctx,policy.ActionDelete,rbac.ResourceSystem);err!=nil {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

We should have a new object type for CryptoKeys

Copy link
CollaboratorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

I went ahead and did this but I'm not sure what adding an object type buys us? I don't believe there's any intent to expose this to users so distinguishing it from other "system resources" doesn't seem to buy us anything.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

A couple things:

  1. Clarity and understandability. "System resources" is currently a dumping ground of a bunch of misc stuff that doesn't actually make sense together. Let's not make it worse. Crypto keys are a specific distinct resource and our code should reflect that.
  2. Limited permissions scope. You're about to write a new subcomponent that interacts with crypto keys. What permissions should it have? Answer: crypto keys and nothing else. Impossible to do if you lump crypto keys in with a bunch of other stuff.

sreya reacted with thumbs up emoji
-- name: GetLatestCryptoKeyByFeature :one
SELECT*
FROM crypto_keys
WHERE feature= $1
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

We have to be a little careful here.

One reason you might want to get the latest key is that you're looking for the current signing key. In that case you need to excludesecret IS NULL.

Another reason is that you might be inserting a new key. In that case you need to include all keys, even ifsecret is NULL.

Might need 2 queries, unless you're depending onGetCryptoKeys to find the signing key.

Copy link
CollaboratorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Yeah the plan is to provide an abstraction like we talked that would wrap this and filter out invalid keys so callers don't have to worry about the details.

Copy link
CollaboratorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

That may be dumb though, might be better to avoid any "cleverness" at all

@sreyasreya merged commit45160c7 intomainSep 17, 2024
@sreyasreya deleted the jon/keyschema branchSeptember 17, 2024 17:08
@github-actionsgithub-actionsbot locked and limited conversation to collaboratorsSep 17, 2024
Sign up for freeto subscribe to this conversation on GitHub. Already have an account?Sign in.

Reviewers

@deansheatherdeansheatherdeansheather approved these changes

@spikecurtisspikecurtisspikecurtis approved these changes

Assignees

@sreyasreya

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

@sreya@spikecurtis@deansheather

[8]ページ先頭

©2009-2025 Movatter.jp