@@ -273,6 +273,7 @@ Effectively the format is::
273273 MaxCertLifetime
274274 SigningKeyFingerprint
275275 PrivateKeyFile
276+ KmsRegion
276277 AuthorizedSigners {
277278 <key fingerprint>: <key identity>
278279 }
@@ -294,10 +295,18 @@ Effectively the format is::
294295 sign complete requests. This should be the fingerprint of your CA. When using
295296 this option you must, somehow, load the private key into the agent such that
296297 the daemon can use it.
297- - ``PrivateKeyFile ``: A path to a private key file. As of this writing the key
298- must be unencrypted. Do take explicit care if you're using unencrypted
299- private keys. The next release / commit will include support for private key
300- files that are encrypted using Amazon's KMS.
298+ - ``PrivateKeyFile ``: A path to a private key file. The key may be
299+ unencrypted or have previously been encrypted using Amazon's KMS. If
300+ the key was encrypted using KMS simply name it with a ".kms" extension
301+ and ssh-cert-authority will attempt to decrypt the key on startup. See
302+ the section on Encrypting a CA Key for help in using KMS to encrypt
303+ the key.
304+ - ``KmsRegion ``: If sign_certd encounters a privatekey file with an
305+ extension of ".kms" it will attempt to decrypt it using KMS in the
306+ same region that the software is running in. It determines this using
307+ the local instance's metadata server. If you're not running
308+ ssh-cert-authority within AWS or if the key is in a different region
309+ you'll need to specify the region here as a string, e.g. us-west-2.
301310- ``AuthorizedSigners ``: A hash keyed by key fingerprints and values of key
302311 ids. I recommend this be set to a username. It will appear in the
303312 resultant SSH certificate in the KeyId field as well in
@@ -336,6 +345,73 @@ You can take that value and add in your keys like so::
336345
337346Once the server is up and running it is bound to 0.0.0.0 on port 8080.
338347
348+ Encrypting a CA Key Using Amazon's KMS
349+ ======================================
350+
351+ Amazon's KMS (Key Management Service) provides an encryption key
352+ management service that can be used to encrypt small chunks of arbitrary
353+ data (including other keys). This project supports using KMS to keep the
354+ CA key secure.
355+
356+ The recommended deployment is to launch ssh-cert-authority onto an EC2
357+ instance that has an EC2 instance profile attached to it that allows it
358+ to use KMS to decrypt the CA key. A sample cloudformation stack is
359+ forthcoming to do all of this on your behalf.
360+
361+ Create Instance Profile
362+ ```````````````````````
363+
364+ In the mean time you can set things up by hand. A sample EC2 instance
365+ profile access policy::
366+
367+ {
368+ "Statement": [
369+ {
370+ "Resource": [
371+ "*"
372+ ],
373+ "Action": [
374+ "kms:Encrypt",
375+ "kms:Decrypt",
376+ "kms:ReEncrypt",
377+ "kms:GenerateDataKey",
378+ "kms:DescribeKey"
379+ ],
380+ "Effect": "Allow"
381+ }
382+ ],
383+ "Version": "2012-10-17"
384+ }
385+
386+ Create KMS Key
387+ ``````````````
388+
389+ Create a KMS key in the AWS IAM console. When specifying key usage allow the
390+ instance profile you created earlier to use the key. The key you create
391+ will have an id associated with it, it looks something like this:
392+
393+ arn:aws: kms:us-west-2: 123412341234:key/debae348-3666-4cc7-9d25-41e33edb2909
394+
395+ Save that for the next step.
396+
397+ Launch Instance
398+ ```````````````
399+
400+ Now launch an instance and use the EC2 instance profile. A t2 class instance is
401+ likely sufficient. Copy over the latest ssh-cert-authority binary (you
402+ can also use the container) and generate a new key for the CA using
403+ ssh-keygen and then use ssh-cert-authority to encrypt it::
404+
405+ environment_name=production
406+ ssh-keygen -q -t rsa -b 4096 -C "ssh-cert-authority ${environment_name}" -f ca-key-${environment_name}
407+ cat ca-key-${environment_name} | ./ssh-cert-authority-linux-amd64 encrypt-key --key-id \
408+ arn:aws:kms:us-west-2:881577346222:key/d1401480-8220-4bb7-a1de-d03dfda44a13 \
409+ --output ca-key-${environment_name}.kms && rm ca-key-${environment_name}
410+
411+ At this point you're ready to fire up the authority. The rest of this
412+ document applies, simply add a PrivateKeyFile option to signer certd's
413+ config for the environment you're working on and reference the path to
414+ the encrypted file we just created, `ca-key-${environment_name}.kms `
339415
340416Requesting Certificates
341417=======================
0 commit comments