-
Notifications
You must be signed in to change notification settings - Fork 128
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
Use kms per client #556
Use kms per client #556
Conversation
Implementation of KMS pre client
# Conflicts: # keystore/filesystem/server_keystore.go # keystore/filesystem/server_keystore_test.go
Fixed conflicts with master
keyID, err := getKeyIDFromContext(keyContext) | ||
if err != nil { | ||
// TODO: add logging | ||
return nil, err |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we can try to get logger from the context via logging.GetLoggerFromContext
function
Fixed after review
Fixed imports
@@ -239,8 +242,10 @@ func newFilesystemKeyStore(privateKeyFolder, publicKeyFolder string, storage Sto | |||
return nil, err | |||
} | |||
} | |||
|
|||
ctx, _ := context.WithTimeout(context.Background(), network.DefaultNetworkTimeout) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you please tell, why there is a timeout in context?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure. It is a good practice to have a timeout for any network operation. We can ignore it for our SCellEncrytor as we don't do any network calls, but for KMS-related stuff, we should have some timeout checking. In the case of KMS unavailability or some network issue, the request will exit (in 60 secs) with an error TimoutExceeded
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And context is a commonly used thing for this case in Go. A great practice to pass context as the first param to the functions
Fixed after review/added integration tests/extend addzone with KMS KEK creating
Added KMS keystore encryptor initialization to acra-translator
Restructure configs
Added KMS keystore encryptor for all keystore use acra tools
cmd/acra-keys/keys/migrate-keys.go
Outdated
@@ -226,7 +226,7 @@ func MigrateV1toV2(srcV1 filesystem.KeyExport, dstV2 keystoreV2.KeyFileImportV1) | |||
|
|||
log.Tracef("Importing %d keys from keystore v1", expected) | |||
for _, key := range keys { | |||
log := log.WithField("purpose", key.Purpose).WithField("id", key.ID) | |||
log := log.WithField("purpose", key.KeyContext.Purpose).WithField("id", keystore.GetKeyContextFromContext(key.KeyContext)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
how key.KeyContext will be logged?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But we are logging key.KeyContext.Purpose
here or what do you mean?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
.WithField("id", keystore.GetKeyContextFromContext(key.KeyContext))
How it will look in log entry? Something like &{ClientID: nil, ZoneID: nil, Context: []byte{0, 12, 42, 321}}
or something else?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not precisely, previously we had
log := log.WithField("purpose", key.Purpose).WithField("id", key.ID)
where key.ID
is simple bytes slice which is strange as it would print something like []byte{0, 12, 42, 321}
So I just repeat the functionality. Here key.KeyContext
is not bytes slice but keystore.KeyContext
struct. So now it will print some bytes slice because of the function.
func GetKeyContextFromContext(keyContext KeyContext) []byte {
if keyContext.ZoneID != nil {
return keyContext.ZoneID
}
if keyContext.ClientID != nil {
return keyContext.ClientID
}
if keyContext.Context != nil {
return keyContext.Context
}
return nil
}
I think it makes sense to wrap with string
to print string data instead of bytes @Lagovas
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1. maybe lets implement String() string to allow logger use this function?
Fixed after review/add integration tests
for new records""" | ||
args = [os.path.join(BINARY_OUTPUT_FOLDER, 'acra-poisonrecordmaker')] | ||
if keys_dir: | ||
args.append('--keys_dir={}'.format(keys_dir)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we pass here keystore version too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, its is required for keymaker
but not for poisonrecordmaker
.
Added keystore_encryption_type flag
Fixed unit tests
Fixed tests/updated CHANGELOG file
Fixed after review
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
great job
Initial Implementation of KMS per client.
This PR contains several significant changes:
keystore.Encryptor
interface - nowEncrypt/Decrypt
method expect to pass KeyContext.KeyContext.Context
kms.Encryptor
andkms.KeyMakingWrapper
which is simple Decorator with kms key creationLeft some TODOs in the code with some open questions to discuss.
Checklist
with new changes