-
Notifications
You must be signed in to change notification settings - Fork 39.8k
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
Add a secretbox and AES-CBC path for encrypt at rest #46916
Conversation
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: smarterclayton The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these OWNERS Files:
You can indicate your approval by writing |
We may decide to go with this to avoid nonce collisions and reduce the need to rotate. |
27094db
to
21c67d7
Compare
Added a CBC mode for comparison:
|
@smarterclayton In context of your comment on #46460 (which is merged now)
I believe we simply need another configuration option for CBC? Is a small change, but perhaps we have to wait till next month for it (and the above changes) to go in now? |
I think given the concerns raised we want config for both cbc and secretbox
ready - I rate the input high enough that I'd consider saying that we need
these in order to ship.
…On Mon, Jun 5, 2017 at 7:59 PM, Saksham Sharma ***@***.***> wrote:
@smarterclayton <https://github.com/smarterclayton> In context of your
comment on #46460 <#46460>
(which is merged now)
We'll need to update this based on #46916
<#46916>
I believe we simply need another configuration option for CBC? Is a small
change, but perhaps we have to wait till next month for it (and the above
changes) to go in now?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#46916 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABG_p1VFfBLqI__rEQ26waKlPPehyPyeks5sBJZOgaJpZM4NvNkY>
.
|
@smarterclayton this seems like a good idea to me. I can update the extension thread with a request to get this in, plus the config change to allow people to use it. Are you writing the config change too? |
I need to sync with @sakshamsharma on that. |
Yeah @simo5 signed off on the encryption stuff so we're only reviewing config. |
Add tests for new transformers
Maybe we can replace the Boolean with an enumerated variable? We can easily add more underlying encryption algorithms later, which have the same parsing logic. It may help reduce a lot of code reuse. |
@destijl did we get release approval for the exception? |
I asked dawn on the thread I started for the exemption, I believe so. |
aesTransformerPrefixV1 = "k8s:enc:aes:v1:" | ||
aesCBCTransformerPrefixV1 = "k8s:enc:aescbc:v1:" | ||
aesGCMTransformerPrefixV1 = "k8s:enc:aesgcm:v1:" | ||
secretboxTransformerPrefixV1 = "k8s:enc:secretbox:v1" | ||
) |
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.
Context:
sakshamsharma 23 hours ago
I would ideally think that we need shorter prefixes. Like: gcm, cbc, secb.
smarterclayton 9 hours ago
We will almost certainly need to version them in the future, and we want to ensure we have enough key space to evolve if we have to.
Versioned prefixes are fine, what I mean is, we could do k8s:enc:secb:v1
etc, because these prefixes are not user/developer/admin facing. Of course, the premise is that these long prefixes are a storage overhead. If this premise is not significant, we can ignore this.
I think the prefixes in the at rest store are as terse as we can make
them to preserve future expansion
|
The release team's decision on the exception request of encrypt secrets in etcd which includes this pr is yes. Thanks! cc/ @kubernetes/kubernetes-release-managers |
Applying labels based on two part review |
Automatic merge from submit-queue (batch tested with PRs 46979, 47078, 47138, 46916) |
Automatic merge from submit-queue (batch tested with PRs 47510, 47516, 47482, 47521, 47537) Fix typo in secretbox transformer prefix Introduced by #46916 via cherry picked commit [here](sakshamsharma@12bb591). Urgent fix in my opinion, ideally should be merged before production. @smarterclayton
Automatic merge from submit-queue Add encryption provider support via environment variables These changes are needed to allow cloud providers to use the encryption providers as an alpha feature. The version checks can be done in the respective cloud providers'. Context: #46460 and #46916 @destijl @jcbsmpsn @smarterclayton
|
||
func TestSecretboxKeyRotation(t *testing.T) { | ||
testErr := fmt.Errorf("test error") | ||
context := value.DefaultContext([]byte("authenticated_data")) |
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.
Why we're passing different values as a context here and bellow while secretboxTransformer
doesn't use the context at all? Why not pass nil
instead?
if stale { | ||
p = value.NewPrefixTransformers(nil, | ||
value.PrefixTransformer{Prefix: []byte("first:"), Transformer: NewSecretboxTransformer(key1)}, | ||
value.PrefixTransformer{Prefix: []byte("second:"), Transformer: NewSecretboxTransformer(key2)}, |
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.
Order the same: looks like code or comment is wrong.
if stale { | ||
p = value.NewPrefixTransformers(nil, | ||
value.PrefixTransformer{Prefix: []byte("first:"), Transformer: NewCBCTransformer(block1)}, | ||
value.PrefixTransformer{Prefix: []byte("second:"), Transformer: NewCBCTransformer(block2)}, |
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.
The same here: the order hasn't been changed.
return result, fmt.Errorf("could not obtain secret for named key %s: %s", keyData.Name, err) | ||
} | ||
|
||
if len(key) != 32 { |
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.
Is there are reason why we're validating key length only for Secretbox?
Looks we can do the same for AES-GCM (16,24,32) and AES-CBC (32).
@smarterclayton Let me know if you agree and I'll prepare PR for that.
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're validating it only for secretbox because it requires a fixed size array as input. AES-GCM returns a sane error itself, if the key size is not valid. For secretbox, if we did not validate and convert it to a [32]byte
safely, it may throw a runtime error. We need to throw a sane error, and AES-GCM already does that. I'm not sure about CBC though.
} | ||
|
||
keyArray := [32]byte{} | ||
copy(keyArray[:], key) |
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.
@smarterclayton Copying the key looks useless. Why we can't use DecodeString()
result as-is?
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.
The intention of copying was to convert a byte slice to a [32]byte
, and, however ugly, this came up as the best way to do it when I verified it via some quick google search 😄
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.
Thank you for the explanation!
Automatic merge from submit-queue (batch tested with PRs 49850, 47782, 50595, 50730, 51341) Fix benchmarks to really test reverse order of the keys **What this PR does / why we need it**: This PR modifies the code to do what comments says -- reverse the order of keys. It also fixes the logic that was wrong and didn't allow stale data. **Special notes for your reviewer**: This change resolves the following review comments: - #41939 (comment) - #46916 (comment) - #46916 (comment) **Release note**: ```release-note NONE ``` PTAL @smarterclayton
Add a secretbox and AES-CBC encrypt at rest provider and alter the config, based on feedback from security review. AES-CBC is more well reviewed and generally fits better with common criteria and FIPS, secretbox is newer and faster than CBC.