From 8e26a5838892da2dbb994163ca83f852187768f4 Mon Sep 17 00:00:00 2001 From: Dirk Wetter Date: Sat, 2 Jan 2021 14:33:52 +0100 Subject: [PATCH 1/3] draft for the intro section --- D06 - Protect Secrets.md | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/D06 - Protect Secrets.md b/D06 - Protect Secrets.md index c6ff3fe..2761639 100644 --- a/D06 - Protect Secrets.md +++ b/D06 - Protect Secrets.md @@ -1,5 +1,27 @@ # D06 - Protect Secrets +Secrets provide access to resources or help encrypting data in transit or at +rest. Secrets could be private SSH keys, private keys for a X509 certificate, +HMACs for JWT or similar cryptograptographic material. Also it could be just +secrets which provide access to something or just holds credentials, like backend +connectors to databases, API keys, image registry keys or any other tokens which +provide access to an internal or external service. + +Likely you cannot avoid always to provide some kind of keys or credentails to +be provided by a container. E.g. the frontend container needs to have access +to a private keyi, otherwise the HTTPS webservice won't start. A container with +a database connector needs to have access to the database credentials. Or, if +you encrypt the database content: this also would require (a) key(s) for encryption +and decryption. + +You could encrypt those private information. But again you would need keys for +it, and those need to be accessible for a container. This would be a chicken an +egg problem. + +The point of this section is how you deal appropriately with secrets, i.e. where +do I store this kind of information, what is appropriate and what not. + + ## Threat Scenarios From cb6078dfb290b37d5b224b6be4658cebe33534c5 Mon Sep 17 00:00:00 2001 From: Dirk Wetter Date: Mon, 4 Jan 2021 10:43:44 +0100 Subject: [PATCH 2/3] Grammar and wording improvements to intro section of D06 --- D06 - Protect Secrets.md | 25 ++++++++++++------------- 1 file changed, 12 insertions(+), 13 deletions(-) diff --git a/D06 - Protect Secrets.md b/D06 - Protect Secrets.md index 2761639..0f862f4 100644 --- a/D06 - Protect Secrets.md +++ b/D06 - Protect Secrets.md @@ -1,21 +1,20 @@ # D06 - Protect Secrets Secrets provide access to resources or help encrypting data in transit or at -rest. Secrets could be private SSH keys, private keys for a X509 certificate, -HMACs for JWT or similar cryptograptographic material. Also it could be just -secrets which provide access to something or just holds credentials, like backend -connectors to databases, API keys, image registry keys or any other tokens which -provide access to an internal or external service. - -Likely you cannot avoid always to provide some kind of keys or credentails to -be provided by a container. E.g. the frontend container needs to have access -to a private keyi, otherwise the HTTPS webservice won't start. A container with -a database connector needs to have access to the database credentials. Or, if -you encrypt the database content: this also would require (a) key(s) for encryption -and decryption. +rest. Secrets could be private keys for a X509 certificate, HMACs for JWT or similar +cryptograptographic material. Also it could be just secrets which provide necessary +access or just holds credentials. Think of backend connectors to databases, API keys, +image registry keys or any other tokens which provide access to an internal or +external service. + +Often you cannot avoid to provide some kind of keys or credentials to be provided +by a container. E.g. the frontend container needs to have access to a private key, +otherwise the HTTPS webservice won't start. Also a container with a database connector +needs to have access to the database credentials. Or, if you encrypt the database +content: somewhere needs to be a key / the keys for encryption and decryption. You could encrypt those private information. But again you would need keys for -it, and those need to be accessible for a container. This would be a chicken an +that, and those need to be accessible for a container. This results in a chicken an egg problem. The point of this section is how you deal appropriately with secrets, i.e. where From f76b1fe631b5c8dc07e894f53578778464d192f4 Mon Sep 17 00:00:00 2001 From: Dirk Wetter Date: Wed, 6 Jan 2021 10:06:31 +0100 Subject: [PATCH 3/3] address some grammar mistakes and a typo --- D06 - Protect Secrets.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/D06 - Protect Secrets.md b/D06 - Protect Secrets.md index 0f862f4..0396cee 100644 --- a/D06 - Protect Secrets.md +++ b/D06 - Protect Secrets.md @@ -1,15 +1,15 @@ # D06 - Protect Secrets Secrets provide access to resources or help encrypting data in transit or at -rest. Secrets could be private keys for a X509 certificate, HMACs for JWT or similar -cryptograptographic material. Also it could be just secrets which provide necessary +rest. Secrets could be private keys for an X509 certificate, HMACs for JWT or similar +cryptographic material. Also, it could be just secrets which provide necessary access or just holds credentials. Think of backend connectors to databases, API keys, image registry keys or any other tokens which provide access to an internal or external service. -Often you cannot avoid to provide some kind of keys or credentials to be provided +Often you cannot avoid providing some kind of keys or credentials to be provided by a container. E.g. the frontend container needs to have access to a private key, -otherwise the HTTPS webservice won't start. Also a container with a database connector +the HTTPS web service won't start otherwise. Also, a container with a database connector needs to have access to the database credentials. Or, if you encrypt the database content: somewhere needs to be a key / the keys for encryption and decryption.