From: Marcus Watts <mwatts@redhat.com>
Date: Thu, 13 Jan 2022 23:05:06 +0000 (-0500)
Subject: rgw/crypt - document that sse-s3 exists.
X-Git-Tag: v18.0.0~968^2~7
X-Git-Url: http://git-server-git.apps.pok.os.sepia.ceph.com/?a=commitdiff_plain;h=c6aae196dfee427670728eccbcd34fa6d59cb77c;p=ceph.git

rgw/crypt - document that sse-s3 exists.

encryption.rst documents which encryption features are available.
I've added a section on sse-s3, and clarified some other details.

Signed-off-by: Marcus Watts <mwatts@redhat.com>
---

diff --git a/doc/radosgw/encryption.rst b/doc/radosgw/encryption.rst
index 2b51e088f535..7cada356d690 100644
--- a/doc/radosgw/encryption.rst
+++ b/doc/radosgw/encryption.rst
@@ -25,13 +25,14 @@ keys and remember which key was used to encrypt each object.
 
 This is implemented in S3 according to the `Amazon SSE-C`_ specification.
 
-As all key management is handled by the client, no special configuration is
-needed to support this encryption mode.
+As all key management is handled by the client, no special Ceph configuration
+is needed to support this encryption mode.
 
 Key Management Service
 ======================
 
-This mode allows keys to be stored in a secure key management service and
+In this mode, an administrator stores keys in a secure key management service.
+These keys are then
 retrieved on demand by the Ceph Object Gateway to serve requests to encrypt
 or decrypt data.
 
@@ -43,12 +44,26 @@ integration with `Barbican`_, `Vault`_, and `KMIP`_ are implemented.
 See `OpenStack Barbican Integration`_, `HashiCorp Vault Integration`_,
 and `KMIP Integration`_.
 
+SSE-S3
+======
+
+This makes key management invisible to the user.  They are still stored
+in vault, but they are automatically created and deleted by Ceph. and
+retrieved as required to serve requests to encrypt
+or decrypt data.
+
+This is implemented in S3 according to the `Amazon SSE-S3`_ specification.
+
+In principle, any key management service could be used here.  Currently
+only integration with `Vault`_, is implemented.
+
+See `HashiCorp Vault Integration`_.
+
 Bucket Encryption APIs
 ======================
 
 Bucket Encryption APIs to support server-side encryption with Amazon
 S3-managed keys (SSE-S3) or AWS KMS customer master keys (SSE-KMS). 
-SSE-KMS implementation via BucketEncryption APIs is not supported yet.
 
 See `PutBucketEncryption`_, `GetBucketEncryption`_, `DeleteBucketEncryption`_
 
@@ -69,6 +84,7 @@ The configuration expects a base64-encoded 256 bit key. For example::
 
 .. _Amazon SSE-C: https://docs.aws.amazon.com/AmazonS3/latest/dev/ServerSideEncryptionCustomerKeys.html
 .. _Amazon SSE-KMS: http://docs.aws.amazon.com/AmazonS3/latest/dev/UsingKMSEncryption.html
+.. _Amazon SSE-S3: https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingServerSideEncryption.html
 .. _Barbican: https://wiki.openstack.org/wiki/Barbican
 .. _Vault: https://www.vaultproject.io/docs/
 .. _KMIP: http://www.oasis-open.org/committees/kmip/
diff --git a/doc/radosgw/vault.rst b/doc/radosgw/vault.rst
index e21b639e9a6f..a5b51b9bd927 100644
--- a/doc/radosgw/vault.rst
+++ b/doc/radosgw/vault.rst
@@ -111,7 +111,7 @@ Token policies for the object gateway
 
 All Vault tokens have powers as specified by the polices attached
 to that token.  Multiple policies may be associated with one
-token.  You should only use the policy necessary for your
+token.  You should only use the policies necessary for your
 configuration.
 
 When using the kv secret engine with the object gateway::
@@ -156,6 +156,18 @@ transit secret engine, you might need the following policy::
     }
   EOF
 
+If you are using both sse-kms and sse-s3, then you should point
+each to separate containers.  You could either use separate
+vault instances, or you could use either separately mounted
+transit instances, or different branches under a common transit
+pointpoint.  If you are not using separate vault instances, you can
+Use these to point kms and sse-s3 to separate containers:
+``rgw_crypt_vault_prefix``
+and/or
+``rgw_crypt_sse_s3_vault_prefix``.
+When granting vault permissions to sse-kms bucket owners, you should
+not give them permission to muck around with sse-s3 keys;
+only ceph itself should be doing that.
 
 Token authentication
 --------------------