Skip to content

feat: add key processor repository#157

Draft
fabenan-f wants to merge 1 commit into
mainfrom
feat/key-processor-repo
Draft

feat: add key processor repository#157
fabenan-f wants to merge 1 commit into
mainfrom
feat/key-processor-repo

Conversation

@fabenan-f

Copy link
Copy Markdown
Contributor

No description provided.

Signed-off-by: fabenan-f <63860771+fabenan-f@users.noreply.github.com>

@apatsap apatsap left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Very nice. I think we should revisit the provider mechanism though

config:
prefix: root-kek
type: unsafe-sqlite-memory
cryptor:

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Cryptor is very go-ish.

What about just calling it crypto or cipher?

"github.com/openkcm/krypton/internal/securemem"
)

const TypeHSM cryptor.Type = "hsm"

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Lets not call it HSM.

Comment thread examples/root.config.yaml
Comment on lines 20 to 21
parent_key_provider:
agent_name: root

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

I know you didn't add this but this is wrong. Since the root doesn't have parent_key_provider but rather K1's cryptor knows how to access the parent.

Maybe you could just remove it

const TypeAES256GCM cryptor.Type = "aes256gcm"

// CryptorConfig is the configuration for an AES-256-GCM cryptor.
type CryptorConfig struct{}

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Nice

Comment thread internal/spec/cryptor.go
Comment on lines +25 to +28
type CryptorBundle struct {
Cryptor cryptor.Cryptor
SecretGenerator cryptor.SecretGenerator
}

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

This is a good idea. But it feels at a wrong place. I think this should live at cryptor.Bundle

Comment thread internal/spec/cryptor.go
type CryptorSpec struct {
Name string `yaml:"name"`
Type cryptor.Type `yaml:"type"`
Config cryptor.Config `yaml:"-"`

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

The yaml shouldn't be excluded. I.e.

type CryptorSpec struct {
...
	Config cryptor.Config `yaml:"config"`
}

Comment thread internal/spec/cryptor.go
return nil
}

func (c *CryptorSpec) Open(ctx context.Context) (CryptorBundle, error) {

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

I think the Open should go away (see long comment) above

Comment thread internal/spec/cryptor.go
func newCryptorConfig(t cryptor.Type) (cryptor.Config, error) {
switch t {
case aes256gcm.TypeAES256GCM:
return &aes256gcm.CryptorConfig{}, nil

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

I think we can make aes256gcm.CryptorConfig impelment the yaml.Marshalller so that it isn't all scattered around

Comment thread internal/spec/vault.go
type VaultSpec struct {
Name string `yaml:"name"`
Type vault.Type `yaml:"type"`
Config vault.Config `yaml:"-"`

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

I think this should be not excluded:

	Config vault.Config `yaml:"config"`

Comment thread internal/spec/vault.go
return nil
}

func (v *VaultSpec) Open(ctx context.Context) (vault.Vault, error) {

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

I'd suggest the same provider mechanism as for the cryptor package

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants