docs(bindings): add example for kms pkey offload #4980
Conversation
| /// s2n-tls requires that future have 'static bounds, so this function can not | ||
| /// operation on `&self`. Instead we clone all of the necessary elements and | ||
| /// capture them in the closure. | ||
| async fn async_pkey_offload( |
There was a problem hiding this comment.
Err I guess I have no suggestions here, but this is really weird. I see what you mean about the ConnectionFuture not really being idiomatic.
bindings/rust-examples/async-pkey-offload/tests/client_server.rs
Outdated
Show resolved
Hide resolved
| OperationType::Sign(Self::EXPECTED_SIG, hash_algorithm) => Ok(hash_algorithm), | ||
|
|
||
| // errors | ||
| OperationType::Sign(_, _) => Err(s2n_tls::error::Error::application( | ||
| "RSA signatures can not be used with EC keys".into(), | ||
| )), | ||
| OperationType::Decrypt => Err(s2n_tls::error::Error::application( | ||
| "Decrypt can not be used with EC keys".into(), | ||
| )), |
There was a problem hiding this comment.
It seems a little odd to have a variable Self::EXPECTED_SIG, but then have the code assume that the signature is EC
There was a problem hiding this comment.
Sorry I'm not quite following. Where is the assumption? The match statement will only return Ok if there is an ECDSA signature, matching against EXPECTED_SIG.
There was a problem hiding this comment.
Since EXPECTED_SIG is just a variable, imagine I decide to set it to s2n_tls::enums::SignatureAlgorithm::RSA. Does this chunk of code still make sense? You'd print "RSA signatures can not be used with EC keys" if an ECDSA signature was requested.
There was a problem hiding this comment.
You'd print "RSA signatures can not be used with EC keys" if an ECDSA signature was requested.
I don't think that's the case. EXPECTED_SIG is a constant, not a variable. If you passed in an RSA signature, the first match arm would not execute. Instead you would get an error saying "RSA signatures can not be used with EC keys".
I updated the playground example to use an associated constant as I'm doing here.
|
|
||
| You can clean up the test resources by running `cargo run --bin delete_demo_keys`. | ||
|
|
There was a problem hiding this comment.
Why don't we handle this automatically?
Having a binary to clean up after a test seems particularly odd. I still wouldn't love it if we had a binary to clean up after another binary, but it'd be a more standard setup.
There was a problem hiding this comment.
Because KMS keys are pretty "sticky". You can't immediately delete them, you can only schedule them for deletion, and the shortest deletion window is 7 days.
If we generated a new key for each invocation and someone reran this demo several times, they would have multiple KMS keys (each of which cost $1 per month).
In general, I expect that people actually running a demo will want to run in multiple times. Examine different parts of the output, etc, which is why delete_demo_keys is a separate binary.
There was a problem hiding this comment.
Can you use a key scheduled for deletion? Could we schedule all our keys for deletion immediately, but the example keeps using them? Maybe with a check that they're <5 days old, if that's a thing?
There was a problem hiding this comment.
Nope. Keys that are pending deletion can not be used for anything.
| // > The public key that AWS KMS returns is a DER-encoded X.509 public key, | ||
| // > also known as SubjectPublicKeyInfo (SPKI), as defined in RFC 5280. | ||
| // > When you use the HTTP API or the AWS CLI, the value is Base64-encoded. | ||
| // > Otherwise, it is not Base64-encoded. | ||
| // https://docs.aws.amazon.com/kms/latest/developerguide/download-public-key.html |
There was a problem hiding this comment.
Nit: I prefer the link first so that I know what I'm reading
There was a problem hiding this comment.
Hmm, I feel like that's a bit non-standard w.r.t block quotes, e.g. apa.
* refactor to list-keys method
* make error message parameterized
Description of changes:
This example demonstrate the pkey offload feature in combination with KMS APIs.
Call-outs:
I structured this example as a test, because it was the only way to keep my sanity while I was writing it. Furthermore, I think this is an excellent item to add to our CI.
While there might be a slight readability hit by structuring it as a "test", I actually think that keeping everything in the same process is a bit of a readability win. There isn't an CLI parsing, etc. So very happy to make the tradeoff.
Testing:
Verified that the test passes locally.
I also opened #4979 to track this.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.