diff --git a/.ansible-lint b/.ansible-lint
index 052bbfe..3c99104 100644
--- a/.ansible-lint
+++ b/.ansible-lint
@@ -3,6 +3,7 @@
offline: true
warn_list:
- - 'name[template]' # Jinja templates should only be at the end of 'name' -- oh come on!
- - 'role-name[path]' # Avoid using paths when importing roles -- yeah, need for testing
+ - name[template] # Jinja templates should only be at the end of 'name' -- oh come on!
+ - role-name[path] # Avoid using paths when importing roles -- yeah, need for testing
+ - yaml[comments-indentation]
- package-latest
diff --git a/.markdownlint.yaml b/.markdownlint.yaml
index 5264fb5..417ec9a 100644
--- a/.markdownlint.yaml
+++ b/.markdownlint.yaml
@@ -9,6 +9,7 @@ MD013: # line-length
code_blocks: false
MD033: # no-inline-html
allowed_elements:
+ - b
- br
- code
- details
diff --git a/knowledge base/cloud computing/aws/ebs.md b/knowledge base/cloud computing/aws/ebs.md
index a098d99..e497c10 100644
--- a/knowledge base/cloud computing/aws/ebs.md
+++ b/knowledge base/cloud computing/aws/ebs.md
@@ -4,6 +4,7 @@ Persistent [block storage][what is block storage?] for [EC2 Instances][ec2].
1. [TL;DR](#tldr)
1. [Snapshots](#snapshots)
+1. [Encryption](#encryption)
1. [Further readings](#further-readings)
1. [Sources](#sources)
@@ -53,6 +54,81 @@ When archived, incremental snapshots are converted to **full snapshots** and mov
When access to archived snapshots is needed, they need to be restored to the standard tier before use. Restoring can
take **up to 72h**.
+## Encryption
+
+Refer [How Amazon EBS encryption works].
+
+One can encrypt both boot and data volumes.
+
+At the time of writing, only **symmetric** keys are supported.
+
+Volumes attached to supported instance types encrypt the following types of data:
+
+- Data **at rest** inside the volume.
+- Data moving between the volume and the attached instance.
+- Snapshots created from the volume.
+- Volumes created from said snapshots.
+
+Volumes are encrypted with a AES-256 data key.
+The key is:
+
+1. Generated by KMS.
+1. Encrypted by KMS with another KMS-managed key.
+1. Stored with the volume's information.
+
+EBS automatically creates a unique AWS-managed key in **each** Region where one creates EBS resources, using the
+`aws/ebs` alias. EBS then uses this KMS key for encryption by default.
+Alternatively, one can use a **symmetric** customer managed encryption key of one's own creation.
+
+EC2 integrates with KMS to encrypt and decrypt EBS volumes in ways that differ depending on whether the original
+snapshot for encrypted volumes is itself encrypted or unencrypted.
+
+
+ The original snapshot is encrypted
+
+1. EC2 sends a `GenerateDataKeyWithoutPlaintext` request to KMS specifying the KMS key for volume encryption.
+1. If the volume is encrypted using the same key as the snapshot, KMS encrypts that key using that same data key as
+ the snapshot.
+ If the volume is encrypted using a different KMS key, KMS generates a new data key and encrypts it using the
+ specified key. The encrypted data key is then sent to EBS to be stored with the volume metadata.
+1. When attaching the encrypted volume to an instance, EC2 sends a `CreateGrant` request to KMS to be allowed to
+ decrypt the data key.
+1. KMS decrypts the encrypted data key and sends the decrypted data key to EC2.
+1. EC2 uses the plaintext data key in the Nitro hardware to encrypt disk I/O to the volume.
+ The plaintext data key persists in memory as long as the volume is attached to the instance.
+
+
+
+
+ The original snapshot is not encrypted
+
+1. EC2 sends a `CreateGrant` request to KMS to be allowed to encrypt the volume that is being created from the snapshot.
+1. EC2 sends a `GenerateDataKeyWithoutPlaintext` request to KMS specifying the key chosen for volume encryption.
+1. KMS generates a new data key, encrypts it using the specified key, and sends the encrypted data key to EBS to be
+ stored with the volume metadata.
+1. EC2 sends a `Decrypt` request to KMS to decrypt the encrypted data key, which it then uses to encrypt the volume's
+ data.
+1. When attaching the encrypted volume to an instance, EC2 sends:
+
+ 1. A `CreateGrant` request to KMS to be allowed to decrypt the data key.
+ 1. A `Decrypt` request to KMS specifying the encrypted data key.
+
+1. KMS decrypts the encrypted data key and sends the decrypted data key back to EC2.
+1. EC2 uses the plaintext data key in the Nitro hardware to encrypt disk I/O to the volume.
+ The plaintext data key persists in memory as long as the volume is attached to the instance.
+
+When KMS keys become unusable, the effect is **almost immediately** subject to **eventual** consistency.
+The key state of the impacted KMS keys change to reflect their new condition, and all requests to use those keys in
+cryptographic operations fail.
+
+EC2 uses the **data** key, not the KMS key itself, to encrypt all disk I/O while a volume is attached to
+the instance. As such, there is **no** immediate effect on the EC2 instance or its attached EBS volumes when performing
+an action that makes a key unusable.
+When the encrypted EBS volume is detached from the instance, however, EBS removes the data key from the Nitro hardware.
+As such, the next time the encrypted EBS volume is attached to an EC2 instance the attachment will fail due EBS being
+unable to use the KMS key to decrypt the volume's encrypted data key. To use the EBS volume again, one must make the KMS
+key usable again.
+
## Further readings
- [Amazon Web Services]
@@ -70,6 +146,7 @@ take **up to 72h**.
- [`describe-volumes`][describe-volumes]
- [`delete-volume`][delete-volume]
- [How do I increase or decrease the size of my EBS volume?]
+- [How Amazon EBS encryption works]