From d758e9f6dfb137a7a24ba98319fe6c6571a828e5 Mon Sep 17 00:00:00 2001 From: Will Tsai <28876888+willtsai@users.noreply.github.com> Date: Fri, 26 Jul 2024 16:01:44 -0700 Subject: [PATCH 01/10] add secret store scenario extension feature specs Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com> --- resources/2024-07-secretstore-feature-spec.md | 229 ++++++++++++++++++ 1 file changed, 229 insertions(+) create mode 100644 resources/2024-07-secretstore-feature-spec.md diff --git a/resources/2024-07-secretstore-feature-spec.md b/resources/2024-07-secretstore-feature-spec.md new file mode 100644 index 00000000..4b098ab5 --- /dev/null +++ b/resources/2024-07-secretstore-feature-spec.md @@ -0,0 +1,229 @@ +# Extend the use-cases of `Applications.Core/secretStores` + +* **Status**: Pending +* **Author**: Will Tsai (@willtsai) + +## Target customers +**Developers and operators** who are building and managing microservice applications, are using Radius to deploy applications and wish to effortlessly and securely manage the secrets for use in their environments and applications. + +## Existing customer problem + +Currently, Radius provides an `Applications.Core/secretStores` resource type that allows developers to store and retrieve secrets in a secure and reliable way. The `secretStores` resource type can be referenced and used by the following Radius resources today: +- `Applications.Core/gateways` to manage [TLS certificates for HTTPS connections](https://docs.radapp.io/guides/author-apps/networking/tls/) +- `Applications.Core/environments` for authentication into [private Recipe registries](https://docs.radapp.io/guides/recipes/terraform/howto-private-registry/), [custom Terraform Providers](https://docs.radapp.io/guides/recipes/terraform/howto-custom-provider/), and in [Recipe configurations](https://github.com/radius-project/radius/blob/594faf60683351e4be2dee7309ebc369dfac26ad/test/functional-portable/corerp/noncloud/resources/testdata/corerp-resources-terraform-postgres.bicep#L32). + +As an operator, I can create a `secretStores` resource to securely manage secrets for use in the Radius Environments I provide for my developers, which is handy to allow for authentication into private Recipe registries and custom Terraform Providers. However, the `secretStores` resource type is not yet supported by the `Applications.Core/containers`, `Applications.Core/extenders`, `Applications.Core/volumes`, `Applications.Datastores/*`, and `Applications.Messaging/*` resource types. Thus, I have to do extra work to inject secrets as environment variables by configuring each custom Recipe in order to propagate secrets to my application developers. + +As an application developer, I cannot reference a `secretStores` resource in the `Applications.Core/containers`, `Applications.Core/extenders`, `Applications.Core/volumes`, `Applications.Datastores/*`, and `Applications.Messaging/*` resource types to securely manage secrets for use in my application. Instead, I'm having to store my secrets in plain text within the `properties.secrets` field for each resource. This is a critical gap in the secret management capabilities of Radius that is hindering my ability to securely manage secrets for use in my containers. + +## Desired customer experience outcome + + +As an operator, I can define an `Applications.Core/secretStores` resource and deploy it along with an Environment so that the developers I support can securely leverage secrets I manage on their behalf for use in their application resources. + +As a developer, I can reference an `Applications.Core/secretStores` in my `Applications.Core/containers` resource defintion so that Radius will inject secrets as environment variables into my container at deploy time so that credentials can be provided to the container for authentication, etc. + +As a developer, I can reference an `Applications.Core/secretStores` in my `Applications.Extenders` or `Applications.Volumes` resource defintion so that I no longer have to store secrets as plain text in the `properties.secrets` field of my resource for authentication, etc. + +As a developer, I can reference an `Applications.Core/secretStores` in my `Applications.Datastores/*` or `Applications.Messaging/*` resource defintion so that I no longer have to store secrets as plain text in the `properties.secrets` field of my resource for authentication, etc. + +### Detailed Customer Experience + + + +Step 1: Operator creates and deploys `Applications.Core/secretStores` resources containing the secret data required for authenticating into resources that their developers may use. + +```bicep +resource authcreds 'Applications.Core/secretStores@2023-10-01-preview' = { + name: 'authcreds' + properties:{ + application: application + type: 'credentials' // this can change based on detailed tech design + data: { + 'username': { + value: username + } + 'password': { + value: password + } + 'uri': { + value: uri + } + 'connectionString': { + value: connectionString + } + } + } +} +``` + +```bicep +resource azurekeyvaultsecrets 'Applications.Core/secretStores@2023-10-01-preview' = { + name: 'azurekeyvaultsecrets' + properties:{ + application: application + type: 'generic' // this can change based on detailed tech design + data: { + 'name': { + value: secret1 + } + 'version': { + value: 1 + } + 'encoding': { + value: 'base64' + } + 'alias': { + value: secretalias + } + } + } +} +``` + +Step 2: Developer references the `Applications.Core/secretStores` resource in their `Applications.Core/containers` resource definition to inject secrets as environment variables into their container at deploy time. + +```bicep +resource demo 'Applications.Core/containers@2023-10-01-preview' = { + name: 'demo' + properties: { + application: application + container: { + image: 'ghcr.io/radius-project/samples/demo:latest' + env:{ + // validate accuracy of referencing the values from the secret store + DB_CONNECTION: authcreds.properties.data.connectionString + } + ports: { + web: { + containerPort: 3000 + } + } + } + } +} +``` + +Step 3: Developer references the `Applications.Core/secretStores` resource in their `Applications.Extenders` or `Applications.Volumes` resource definition to securely manage secrets for use in their application. + +```bicep +resource twilio 'Applications.Core/extenders@2023-10-01-preview' = { + name: 'twilio' + properties: { + application: application + environment: environment + recipe: { + name: 'twilio' + } + secrets: { + // validate accuracy of referencing the values from the secret store + password: authcreds.properties.data.password + } + } +} +``` + +```bicep +resource volume 'Applications.Core/volumes@2023-10-01-preview' = { + name: 'myvolume' + properties: { + application: app.id + kind: 'azure.com.keyvault' + resource: keyvault.id + secrets: { + mysecret: { + // validate accuracy of referencing the values from the secret store + name: azurekeyvaultsecrets.properties.data.name + version: azurekeyvaultsecrets.properties.data.version + alias: azurekeyvaultsecrets.properties.data.alias + encoding: azurekeyvaultsecrets.properties.data.encoding + } + } + } +} +``` + +Step 4: Developer references the `Applications.Core/secretStores` resource in their `Applications.Datastores/*` or `Applications.Messaging/*` resource definition to securely manage secrets for use in their application. + +```bicep +resource db 'Applications.Datastores/mongoDatabases@2023-10-01-preview' = { + name: 'db' + properties: { + environment: environment + application: app.id + resourceProvisioning: 'manual' + host: substring(cosmosAccount.properties.documentEndpoint, 0, lastIndexOf(cosmosAccount.properties.documentEndpoint, ':')) + port: int(split(substring(cosmosAccount.properties.documentEndpoint,lastIndexOf(cosmosAccount.properties.documentEndpoint, ':') + 1), '/')[0]) + database: cosmosAccount::database.name + username: '' + resources: [ + { id: cosmosAccount.id } + ] + secrets: { + // validate accuracy of referencing the values from the secret store + connectionString: authcreds.properties.data.connectionString + password: authcreds.properties.data.password + } + } +} +``` + +```bicep +resource rabbitmq 'Applications.Messaging/rabbitmqQueues@2023-10-01-preview' = { + name: 'rabbitmq' + properties: { + environment: environment + application: app.id + resourceProvisioning: 'manual' + queue: 'radius-queue' + host: rmqHost + port: rmqPort + vHost: vHost + username: rmqUsername + secrets: { + // validate accuracy of referencing the values from the secret store + password: authcreds.properties.data.password + } + } +} +``` + +Step 5: Developer deploys the resources to Radius and the secrets required for authentication are injected into the container, extender, volume, datastore, or messaging resource at deploy time. + +## Key investments + + +### Feature 1: Add functionality to reference `Applications.Core/secretStores` in `Applications.Core/containers` resources + +Add the ability for developers to reference values from their `Applications.Core/secretStores` resources in their `Applications.Core/containers` resource definitions under the `properties.container.env` field so that secrets can be injected as environment variables into their container at deploy time. + +### Feature 2: Add functionality to reference `Applications.Core/secretStores` in `Applications.Core/*` resources + +Add the ability for developers to reference values from their `Applications.Core/secretStores` resources in their core resources (namely `Applications.Core/extenders` and `Applications.Core/volumes`) so that secrets can be securely managed for use in their application to authenticate into those resources. + +### Feature 3: Add functionality to reference `Applications.Core/secretStores` in portable resources + +Add the ability for developers to reference values from their `Applications.Core/secretStores` resources in their portable resources (namely `Applications.Datastores/*` and `Applications.Messaging/*`) so that secrets can be securely managed for use in their application to authenticate into those resources. + +## Key dependencies and risks + + + + + +**Dependency: ability to reference values from `Applications.Core/secretStores`.** This feature is dependent on the ability to reference values from `Applications.Core/secretStores`, which should be doable given the existing functionality of referencing secret values for TLS Termination in `Applications.Core/gateways`. + +**Risk: use of secrets in core and portable resources.** This pattern of referencing and leveraging secrets in core and portable resources might not be a common or desirable pattern for users. We will validate this by opening up this feature spec for discussion with the community. + +## Key assumptions to test and questions to answer + + + +**Assumption: operators can create and deploy `Applications.Core/secretStores` resources.** We assume that operators create and manage secrets on behalf of developers, which are encapsulated in `Applications.Core/secretStores` resources. The developers can subsequently reference these resources in their application resources to securely manage secrets for use in their applications. We will validate this assumption by opening up this feature spec for discussion with the community. + +## Current state + +- Feature request tracking this scenario: https://github.com/radius-project/radius/issues/5520 +- Pull request (work in progress) for adding secretstore references into container env variables: https://github.com/radius-project/radius/pull/7744 \ No newline at end of file From 1338afec6a4829f2510ace89d1eef522f17dc24a Mon Sep 17 00:00:00 2001 From: Will Tsai <28876888+willtsai@users.noreply.github.com> Date: Fri, 26 Jul 2024 16:05:14 -0700 Subject: [PATCH 02/10] spelling corrections Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com> --- .github/config/en-custom.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/.github/config/en-custom.txt b/.github/config/en-custom.txt index 8d424819..aa7f7424 100644 --- a/.github/config/en-custom.txt +++ b/.github/config/en-custom.txt @@ -686,4 +686,6 @@ roundtrips reimplement keyspace upsert -TTL \ No newline at end of file +TTL +Tsai +willtsai \ No newline at end of file From c0ebedb2365b81891d5b07e222726154f6f51b41 Mon Sep 17 00:00:00 2001 From: Will Tsai <28876888+willtsai@users.noreply.github.com> Date: Fri, 26 Jul 2024 16:06:08 -0700 Subject: [PATCH 03/10] spelling corrections Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com> --- resources/2024-07-secretstore-feature-spec.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/resources/2024-07-secretstore-feature-spec.md b/resources/2024-07-secretstore-feature-spec.md index 4b098ab5..5da39c7a 100644 --- a/resources/2024-07-secretstore-feature-spec.md +++ b/resources/2024-07-secretstore-feature-spec.md @@ -21,11 +21,11 @@ As an application developer, I cannot reference a `secretStores` resource in the As an operator, I can define an `Applications.Core/secretStores` resource and deploy it along with an Environment so that the developers I support can securely leverage secrets I manage on their behalf for use in their application resources. -As a developer, I can reference an `Applications.Core/secretStores` in my `Applications.Core/containers` resource defintion so that Radius will inject secrets as environment variables into my container at deploy time so that credentials can be provided to the container for authentication, etc. +As a developer, I can reference an `Applications.Core/secretStores` in my `Applications.Core/containers` resource definition so that Radius will inject secrets as environment variables into my container at deploy time so that credentials can be provided to the container for authentication, etc. -As a developer, I can reference an `Applications.Core/secretStores` in my `Applications.Extenders` or `Applications.Volumes` resource defintion so that I no longer have to store secrets as plain text in the `properties.secrets` field of my resource for authentication, etc. +As a developer, I can reference an `Applications.Core/secretStores` in my `Applications.Extenders` or `Applications.Volumes` resource definition so that I no longer have to store secrets as plain text in the `properties.secrets` field of my resource for authentication, etc. -As a developer, I can reference an `Applications.Core/secretStores` in my `Applications.Datastores/*` or `Applications.Messaging/*` resource defintion so that I no longer have to store secrets as plain text in the `properties.secrets` field of my resource for authentication, etc. +As a developer, I can reference an `Applications.Core/secretStores` in my `Applications.Datastores/*` or `Applications.Messaging/*` resource definition so that I no longer have to store secrets as plain text in the `properties.secrets` field of my resource for authentication, etc. ### Detailed Customer Experience From 443523e4895f1da7a13c0e71c6d67de2ba1ee178 Mon Sep 17 00:00:00 2001 From: Will Tsai <28876888+willtsai@users.noreply.github.com> Date: Thu, 1 Aug 2024 15:39:59 -0700 Subject: [PATCH 04/10] add content Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com> --- resources/2024-07-secretstore-feature-spec.md | 39 +++++++++++++------ 1 file changed, 28 insertions(+), 11 deletions(-) diff --git a/resources/2024-07-secretstore-feature-spec.md b/resources/2024-07-secretstore-feature-spec.md index 5da39c7a..49cb035c 100644 --- a/resources/2024-07-secretstore-feature-spec.md +++ b/resources/2024-07-secretstore-feature-spec.md @@ -3,10 +3,10 @@ * **Status**: Pending * **Author**: Will Tsai (@willtsai) -## Target customers +## Target users **Developers and operators** who are building and managing microservice applications, are using Radius to deploy applications and wish to effortlessly and securely manage the secrets for use in their environments and applications. -## Existing customer problem +## Existing user problem Currently, Radius provides an `Applications.Core/secretStores` resource type that allows developers to store and retrieve secrets in a secure and reliable way. The `secretStores` resource type can be referenced and used by the following Radius resources today: - `Applications.Core/gateways` to manage [TLS certificates for HTTPS connections](https://docs.radapp.io/guides/author-apps/networking/tls/) @@ -16,8 +16,7 @@ As an operator, I can create a `secretStores` resource to securely manage secret As an application developer, I cannot reference a `secretStores` resource in the `Applications.Core/containers`, `Applications.Core/extenders`, `Applications.Core/volumes`, `Applications.Datastores/*`, and `Applications.Messaging/*` resource types to securely manage secrets for use in my application. Instead, I'm having to store my secrets in plain text within the `properties.secrets` field for each resource. This is a critical gap in the secret management capabilities of Radius that is hindering my ability to securely manage secrets for use in my containers. -## Desired customer experience outcome - +## Desired user experience outcome As an operator, I can define an `Applications.Core/secretStores` resource and deploy it along with an Environment so that the developers I support can securely leverage secrets I manage on their behalf for use in their application resources. @@ -27,15 +26,33 @@ As a developer, I can reference an `Applications.Core/secretStores` in my `Appli As a developer, I can reference an `Applications.Core/secretStores` in my `Applications.Datastores/*` or `Applications.Messaging/*` resource definition so that I no longer have to store secrets as plain text in the `properties.secrets` field of my resource for authentication, etc. -### Detailed Customer Experience - - +### Detailed User Experience Step 1: Operator creates and deploys `Applications.Core/secretStores` resources containing the secret data required for authenticating into resources that their developers may use. -```bicep +```diff +resource authcreds 'Applications.Core/secretStores@2023-10-01-preview' = { + name: 'authcreds' + properties:{ + application: application + type: 'generic' + data: { + 'username': { + value: username + } + 'password': { + value: password + } + 'uri': { + value: uri + } + 'connectionString': { + value: connectionString + } + } + } +}, + resource authcreds 'Applications.Core/secretStores@2023-10-01-preview' = { name: 'authcreds' properties:{ @@ -219,7 +236,7 @@ Add the ability for developers to reference values from their `Applications.Core ## Key assumptions to test and questions to answer - + **Assumption: operators can create and deploy `Applications.Core/secretStores` resources.** We assume that operators create and manage secrets on behalf of developers, which are encapsulated in `Applications.Core/secretStores` resources. The developers can subsequently reference these resources in their application resources to securely manage secrets for use in their applications. We will validate this assumption by opening up this feature spec for discussion with the community. From 613151593b990388760fb067e3cd42329c9118cf Mon Sep 17 00:00:00 2001 From: Will Tsai <28876888+willtsai@users.noreply.github.com> Date: Thu, 1 Aug 2024 15:44:58 -0700 Subject: [PATCH 05/10] add content Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com> --- resources/2024-07-secretstore-feature-spec.md | 24 +------------------ 1 file changed, 1 insertion(+), 23 deletions(-) diff --git a/resources/2024-07-secretstore-feature-spec.md b/resources/2024-07-secretstore-feature-spec.md index 49cb035c..ffb7a875 100644 --- a/resources/2024-07-secretstore-feature-spec.md +++ b/resources/2024-07-secretstore-feature-spec.md @@ -35,29 +35,7 @@ resource authcreds 'Applications.Core/secretStores@2023-10-01-preview' = { name: 'authcreds' properties:{ application: application - type: 'generic' - data: { - 'username': { - value: username - } - 'password': { - value: password - } - 'uri': { - value: uri - } - 'connectionString': { - value: connectionString - } - } - } -}, - -resource authcreds 'Applications.Core/secretStores@2023-10-01-preview' = { - name: 'authcreds' - properties:{ - application: application - type: 'credentials' // this can change based on detailed tech design ++ type: 'credentials' // this can change based on detailed tech design data: { 'username': { value: username From 38a8ee3530b91d014792f45094bbcc1bcdebc34a Mon Sep 17 00:00:00 2001 From: Will Tsai <28876888+willtsai@users.noreply.github.com> Date: Mon, 5 Aug 2024 10:42:49 -0700 Subject: [PATCH 06/10] address feedback on proposed examples Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com> --- resources/2024-07-secretstore-feature-spec.md | 108 ++++++++++++++---- 1 file changed, 85 insertions(+), 23 deletions(-) diff --git a/resources/2024-07-secretstore-feature-spec.md b/resources/2024-07-secretstore-feature-spec.md index ffb7a875..6b9b849e 100644 --- a/resources/2024-07-secretstore-feature-spec.md +++ b/resources/2024-07-secretstore-feature-spec.md @@ -30,12 +30,12 @@ As a developer, I can reference an `Applications.Core/secretStores` in my `Appli Step 1: Operator creates and deploys `Applications.Core/secretStores` resources containing the secret data required for authenticating into resources that their developers may use. -```diff +```bicep resource authcreds 'Applications.Core/secretStores@2023-10-01-preview' = { name: 'authcreds' properties:{ application: application -+ type: 'credentials' // this can change based on detailed tech design + type: 'generic' // this can change based on detailed tech design data: { 'username': { value: username @@ -80,7 +80,9 @@ resource azurekeyvaultsecrets 'Applications.Core/secretStores@2023-10-01-preview Step 2: Developer references the `Applications.Core/secretStores` resource in their `Applications.Core/containers` resource definition to inject secrets as environment variables into their container at deploy time. -```bicep +> The example below follows the implementation that is currently proposed in https://github.com/radius-project/radius/pull/7744 + +```diff resource demo 'Applications.Core/containers@2023-10-01-preview' = { name: 'demo' properties: { @@ -88,8 +90,14 @@ resource demo 'Applications.Core/containers@2023-10-01-preview' = { container: { image: 'ghcr.io/radius-project/samples/demo:latest' env:{ - // validate accuracy of referencing the values from the secret store - DB_CONNECTION: authcreds.properties.data.connectionString ++ DB_CONNECTION: { ++ valueFrom: { ++ secretRef: { ++ source: authcreds.id ++ key: 'username' ++ } ++ } ++ } } ports: { web: { @@ -103,7 +111,7 @@ resource demo 'Applications.Core/containers@2023-10-01-preview' = { Step 3: Developer references the `Applications.Core/secretStores` resource in their `Applications.Extenders` or `Applications.Volumes` resource definition to securely manage secrets for use in their application. -```bicep +```diff resource twilio 'Applications.Core/extenders@2023-10-01-preview' = { name: 'twilio' properties: { @@ -113,14 +121,20 @@ resource twilio 'Applications.Core/extenders@2023-10-01-preview' = { name: 'twilio' } secrets: { - // validate accuracy of referencing the values from the secret store - password: authcreds.properties.data.password ++ password: { ++ valueFrom: { ++ secretRef: { ++ source: authcreds.id ++ key: 'password' ++ } ++ } ++ } } } } ``` -```bicep +```diff resource volume 'Applications.Core/volumes@2023-10-01-preview' = { name: 'myvolume' properties: { @@ -129,11 +143,38 @@ resource volume 'Applications.Core/volumes@2023-10-01-preview' = { resource: keyvault.id secrets: { mysecret: { - // validate accuracy of referencing the values from the secret store - name: azurekeyvaultsecrets.properties.data.name - version: azurekeyvaultsecrets.properties.data.version - alias: azurekeyvaultsecrets.properties.data.alias - encoding: azurekeyvaultsecrets.properties.data.encoding ++ name: { ++ valueFrom: { ++ secretRef: { ++ source: azurekeyvaultsecrets.id ++ key: 'name' ++ } ++ } ++ } ++ version: { ++ valueFrom: { ++ secretRef: { ++ source: azurekeyvaultsecrets.id ++ key: 'version' ++ } ++ } ++ } ++ alias: { ++ valueFrom: { ++ secretRef: { ++ source: azurekeyvaultsecrets.id ++ key: 'alias' ++ } ++ } ++ } ++ encoding: { ++ valueFrom: { ++ secretRef: { ++ source: azurekeyvaultsecrets.id ++ key: 'encoding' ++ } ++ } ++ } } } } @@ -142,7 +183,7 @@ resource volume 'Applications.Core/volumes@2023-10-01-preview' = { Step 4: Developer references the `Applications.Core/secretStores` resource in their `Applications.Datastores/*` or `Applications.Messaging/*` resource definition to securely manage secrets for use in their application. -```bicep +```diff resource db 'Applications.Datastores/mongoDatabases@2023-10-01-preview' = { name: 'db' properties: { @@ -157,15 +198,28 @@ resource db 'Applications.Datastores/mongoDatabases@2023-10-01-preview' = { { id: cosmosAccount.id } ] secrets: { - // validate accuracy of referencing the values from the secret store - connectionString: authcreds.properties.data.connectionString - password: authcreds.properties.data.password ++ connectionString: { ++ valueFrom: { ++ secretRef: { ++ source: authcreds.id ++ key: 'connectionString' ++ } ++ } ++ } ++ password: { ++ valueFrom: { ++ secretRef: { ++ source: authcreds.id ++ key: 'password' ++ } ++ } ++ } } } } ``` -```bicep +```diff resource rabbitmq 'Applications.Messaging/rabbitmqQueues@2023-10-01-preview' = { name: 'rabbitmq' properties: { @@ -178,14 +232,20 @@ resource rabbitmq 'Applications.Messaging/rabbitmqQueues@2023-10-01-preview' = { vHost: vHost username: rmqUsername secrets: { - // validate accuracy of referencing the values from the secret store - password: authcreds.properties.data.password ++ password: { ++ valueFrom: { ++ secretRef: { ++ source: authcreds.id ++ key: 'password' ++ } ++ } ++ } } } } ``` -Step 5: Developer deploys the resources to Radius and the secrets required for authentication are injected into the container, extender, volume, datastore, or messaging resource at deploy time. +Step 5: Developer deploys the resources to Radius and the secrets required are either injected into the container as environment variables or used as credentials for authentication into the extender, volume, datastore, or messaging resource at deploy time. ## Key investments @@ -208,7 +268,9 @@ Add the ability for developers to reference values from their `Applications.Core -**Dependency: ability to reference values from `Applications.Core/secretStores`.** This feature is dependent on the ability to reference values from `Applications.Core/secretStores`, which should be doable given the existing functionality of referencing secret values for TLS Termination in `Applications.Core/gateways`. +**Dependency: ability to reference values from `Applications.Core/secretStores`.** This feature is dependent on the ability to reference values from `Applications.Core/secretStores`, which should be doable given the existing functionality of referencing secret values for TLS Termination in `Applications.Core/gateways`. + +> The TLS certificate data secret in `Applications.Core/gateways` is referenced today by `tls: { certificateFrom: secretstore.id }`. As a part of implementation we should evaluate if the `valueFrom: { secretRef: { ... } }` pattern proposed here is an acceptable deviation from the previous pattern implemented for `gateways`. **Risk: use of secrets in core and portable resources.** This pattern of referencing and leveraging secrets in core and portable resources might not be a common or desirable pattern for users. We will validate this by opening up this feature spec for discussion with the community. From 796b4a9eabaabe1a2140d4845550de4e89cebe29 Mon Sep 17 00:00:00 2001 From: Will Tsai <28876888+willtsai@users.noreply.github.com> Date: Fri, 1 Nov 2024 15:00:49 -0700 Subject: [PATCH 07/10] address review feedback Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com> --- resources/2024-07-secretstore-feature-spec.md | 143 +++++++++++++++++- 1 file changed, 135 insertions(+), 8 deletions(-) diff --git a/resources/2024-07-secretstore-feature-spec.md b/resources/2024-07-secretstore-feature-spec.md index 6b9b849e..199885bb 100644 --- a/resources/2024-07-secretstore-feature-spec.md +++ b/resources/2024-07-secretstore-feature-spec.md @@ -1,6 +1,5 @@ # Extend the use-cases of `Applications.Core/secretStores` -* **Status**: Pending * **Author**: Will Tsai (@willtsai) ## Target users @@ -14,12 +13,16 @@ Currently, Radius provides an `Applications.Core/secretStores` resource type tha As an operator, I can create a `secretStores` resource to securely manage secrets for use in the Radius Environments I provide for my developers, which is handy to allow for authentication into private Recipe registries and custom Terraform Providers. However, the `secretStores` resource type is not yet supported by the `Applications.Core/containers`, `Applications.Core/extenders`, `Applications.Core/volumes`, `Applications.Datastores/*`, and `Applications.Messaging/*` resource types. Thus, I have to do extra work to inject secrets as environment variables by configuring each custom Recipe in order to propagate secrets to my application developers. +As an operator, I cannot reference a `secretStores` resource in the Recipes I create in order to securely manage secrets to be used in the Recipe configurations. Instead, I'm having to store my secrets in plain text within the `secrets` field of my Recipe's `output` object. This is a critical gap in the secret management capabilities of Radius that is hindering my ability to securely manage secrets for use in my Recipes. + As an application developer, I cannot reference a `secretStores` resource in the `Applications.Core/containers`, `Applications.Core/extenders`, `Applications.Core/volumes`, `Applications.Datastores/*`, and `Applications.Messaging/*` resource types to securely manage secrets for use in my application. Instead, I'm having to store my secrets in plain text within the `properties.secrets` field for each resource. This is a critical gap in the secret management capabilities of Radius that is hindering my ability to securely manage secrets for use in my containers. ## Desired user experience outcome As an operator, I can define an `Applications.Core/secretStores` resource and deploy it along with an Environment so that the developers I support can securely leverage secrets I manage on their behalf for use in their application resources. +As an operator, I can reference an `Applications.Core/secretStores` in my Recipes so that I no longer have to store secrets as plain text in the `secrets` field of my Recipe's `output` object for authentication, etc. + As a developer, I can reference an `Applications.Core/secretStores` in my `Applications.Core/containers` resource definition so that Radius will inject secrets as environment variables into my container at deploy time so that credentials can be provided to the container for authentication, etc. As a developer, I can reference an `Applications.Core/secretStores` in my `Applications.Extenders` or `Applications.Volumes` resource definition so that I no longer have to store secrets as plain text in the `properties.secrets` field of my resource for authentication, etc. @@ -28,14 +31,17 @@ As a developer, I can reference an `Applications.Core/secretStores` in my `Appli ### Detailed User Experience -Step 1: Operator creates and deploys `Applications.Core/secretStores` resources containing the secret data required for authenticating into resources that their developers may use. +Step 1: Operator creates or references an existing `Applications.Core/secretStores` resource containing the secret data required for authenticating into resources that their developers may use. + +Creating a new `secretStore` resource: ```bicep resource authcreds 'Applications.Core/secretStores@2023-10-01-preview' = { name: 'authcreds' properties:{ application: application - type: 'generic' // this can change based on detailed tech design + // today the type is an enum, see https://github.com/radius-project/radius/pull/7816 + type: 'generic' data: { 'username': { value: username @@ -54,12 +60,16 @@ resource authcreds 'Applications.Core/secretStores@2023-10-01-preview' = { } ``` +Referencing an existing `secretStore` resource: + ```bicep resource azurekeyvaultsecrets 'Applications.Core/secretStores@2023-10-01-preview' = { - name: 'azurekeyvaultsecrets' + name: 'existing-azurekeyvault-secrets' properties:{ application: application - type: 'generic' // this can change based on detailed tech design + resource: 'secret-app-existing-secret' + // today the type is an enum, see https://github.com/radius-project/radius/pull/7816 + type: 'generic' data: { 'name': { value: secret1 @@ -78,9 +88,79 @@ resource azurekeyvaultsecrets 'Applications.Core/secretStores@2023-10-01-preview } ``` +Step 2: Operator references the `Applications.Core/secretStores` resource in their Recipe's `output` object to securely pass secrets as outputs to Radius that can be used in provisioning and deploying the resource using the Recipe. + +Bicep example: +```diff +param context object + +@description('The ID of the subnet where the Azure Cache for Redis will be deployed') +param subnetID string = '' + +@description('The location of the Azure Cache for Redis') +param location string = resourceGroup().location + +resource redis 'Microsoft.Cache/redis@2022-05-01' = { + name: 'redis-${uniqueString(context.resource.id)}' + location: location + properties: { + sku: { + capacity: 1 + family: 'P' + name: 'Premium' + } + enableNonSslPort: true + minimumTlsVersion: '1.2' + subnetId: subnetID == '' ? null : subnetID + } +} + +output result object = { + values: { + host: redis.properties.hostName + port: redis.properties.port + username: '' + } + secrets: { ++ password: { ++ valueFrom: { ++ secretRef: { ++ source: authcreds.id ++ key: 'password' ++ } ++ } ++ } + } +} +``` + +Terraform example: +```diff +output "result" { + description = "Output of the recipe. These values will be used to configure connections." + + value = { + values = { + host = memory_db.cluster_endpoint_address + port = memory_db.cluster_endpoint_port + } + secrets = { ++ password = { ++ valueFrom = { ++ secretRef = { ++ source = authcreds.id ++ key = "password" ++ } ++ } ++ } + } + } +} +``` + Step 2: Developer references the `Applications.Core/secretStores` resource in their `Applications.Core/containers` resource definition to inject secrets as environment variables into their container at deploy time. -> The example below follows the implementation that is currently proposed in https://github.com/radius-project/radius/pull/7744 +> The example below follows the implementation that has been completed in https://github.com/radius-project/radius/pull/7744 ```diff resource demo 'Applications.Core/containers@2023-10-01-preview' = { @@ -245,7 +325,38 @@ resource rabbitmq 'Applications.Messaging/rabbitmqQueues@2023-10-01-preview' = { } ``` -Step 5: Developer deploys the resources to Radius and the secrets required are either injected into the container as environment variables or used as credentials for authentication into the extender, volume, datastore, or messaging resource at deploy time. +Step 5: The developer specifies the `Applications.Core/secretStores` resource as a parameter to the Bicep resource that requires the secret. + +```bicep +param secretStore object = authcreds + +resource demo 'Applications.Core/containers@2023-10-01-preview' = { + name: 'demo' + properties: { + application: application + container: { + image: 'ghcr.io/radius-project/samples/demo:latest' + env:{ + DB_CONNECTION: { + valueFrom: { + secretRef: { + source: secretStore.id + key: 'username' + } + } + } + } + ports: { + web: { + containerPort: 3000 + } + } + } + } +} +``` + +Step 6: Developer deploys the resources to Radius and the secrets required are either injected into the container as environment variables or used as credentials for authentication into the extender, volume, datastore, or messaging resource at deploy time. ## Key investments @@ -262,6 +373,12 @@ Add the ability for developers to reference values from their `Applications.Core Add the ability for developers to reference values from their `Applications.Core/secretStores` resources in their portable resources (namely `Applications.Datastores/*` and `Applications.Messaging/*`) so that secrets can be securely managed for use in their application to authenticate into those resources. +> We should revisit the overall plan for provisioning types we plan to support on portable resources before implementing this change. There are some changes with UDT that haven't been solidified yet. + +### Feature 4: Add functionality to reference `Applications.Core/secretStores` objects as a parameter to a Bicep resource + +Add the ability for developers to specify the `Applications.Core/secretStores` resource as a parameter of the `object` type to the Bicep resource that requires the secret so that secrets can be passed as parameters into a Radius Bicep resource. + ## Key dependencies and risks @@ -280,7 +397,17 @@ Add the ability for developers to reference values from their `Applications.Core **Assumption: operators can create and deploy `Applications.Core/secretStores` resources.** We assume that operators create and manage secrets on behalf of developers, which are encapsulated in `Applications.Core/secretStores` resources. The developers can subsequently reference these resources in their application resources to securely manage secrets for use in their applications. We will validate this assumption by opening up this feature spec for discussion with the community. +**Assumption: the `Applications.secretStores` resource type can be referenced as a parameter to a Bicep resource.** We assume that the `Applications.secretStores` resource type can be referenced as a parameter to a Bicep resource so that secrets can be passed as object parameters into a Radius Bicep resource. We will validate this assumption by investigating the feasibility of this approach during tech design. + ## Current state - Feature request tracking this scenario: https://github.com/radius-project/radius/issues/5520 -- Pull request (work in progress) for adding secretstore references into container env variables: https://github.com/radius-project/radius/pull/7744 \ No newline at end of file +- Pull request (work in progress) for adding secretstore references into container env variables: https://github.com/radius-project/radius/pull/7744 + +## Design Review Notes + +- Considerations for `Applications.Core/secretstores` resource `type` values -- *this has been addressed by [PR #7816](https://github.com/radius-project/radius/pull/7816) and referenced in this feature spec doc* +- Discussion around whether `Applications.Core/secretStores` is right, specifically whether it should be part of `Applications.Core` or whether it should be part of UCP (something like `System.Resources/secretStores`) -- *this is a larger discussion beyond the scope of this particular feature spec* +- Scenario that allows for secrets to be passed as parameters into a Radius Bicep resource is missing -- *this scenario was added* +- Need scenarios for referencing `Applications.Core/secretStores` in Radius Recipes -- *this scenario was added* +- Add more information on customers bringing in their own secrets, secrets stores resource currently supporting only k8s secrets -- TODO \ No newline at end of file From 8bed4df0e9edad8df821ed6a3ca35243ca4550dc Mon Sep 17 00:00:00 2001 From: Will Tsai <28876888+willtsai@users.noreply.github.com> Date: Fri, 1 Nov 2024 15:31:37 -0700 Subject: [PATCH 08/10] add recipes scenario Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com> --- resources/2024-07-secretstore-feature-spec.md | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/resources/2024-07-secretstore-feature-spec.md b/resources/2024-07-secretstore-feature-spec.md index 199885bb..472d027d 100644 --- a/resources/2024-07-secretstore-feature-spec.md +++ b/resources/2024-07-secretstore-feature-spec.md @@ -158,7 +158,7 @@ output "result" { } ``` -Step 2: Developer references the `Applications.Core/secretStores` resource in their `Applications.Core/containers` resource definition to inject secrets as environment variables into their container at deploy time. +Step 3: Developer references the `Applications.Core/secretStores` resource in their `Applications.Core/containers` resource definition to inject secrets as environment variables into their container at deploy time. > The example below follows the implementation that has been completed in https://github.com/radius-project/radius/pull/7744 @@ -189,7 +189,7 @@ resource demo 'Applications.Core/containers@2023-10-01-preview' = { } ``` -Step 3: Developer references the `Applications.Core/secretStores` resource in their `Applications.Extenders` or `Applications.Volumes` resource definition to securely manage secrets for use in their application. +Step 4: Developer references the `Applications.Core/secretStores` resource in their `Applications.Extenders` or `Applications.Volumes` resource definition to securely manage secrets for use in their application. ```diff resource twilio 'Applications.Core/extenders@2023-10-01-preview' = { @@ -261,7 +261,7 @@ resource volume 'Applications.Core/volumes@2023-10-01-preview' = { } ``` -Step 4: Developer references the `Applications.Core/secretStores` resource in their `Applications.Datastores/*` or `Applications.Messaging/*` resource definition to securely manage secrets for use in their application. +Step 5: Developer references the `Applications.Core/secretStores` resource in their `Applications.Datastores/*` or `Applications.Messaging/*` resource definition to securely manage secrets for use in their application. ```diff resource db 'Applications.Datastores/mongoDatabases@2023-10-01-preview' = { @@ -325,7 +325,7 @@ resource rabbitmq 'Applications.Messaging/rabbitmqQueues@2023-10-01-preview' = { } ``` -Step 5: The developer specifies the `Applications.Core/secretStores` resource as a parameter to the Bicep resource that requires the secret. +Step 6: The developer specifies the `Applications.Core/secretStores` resource as a parameter to the Bicep resource that requires the secret. ```bicep param secretStore object = authcreds @@ -356,7 +356,7 @@ resource demo 'Applications.Core/containers@2023-10-01-preview' = { } ``` -Step 6: Developer deploys the resources to Radius and the secrets required are either injected into the container as environment variables or used as credentials for authentication into the extender, volume, datastore, or messaging resource at deploy time. +Step 7: Developer deploys the resources to Radius and the secrets required are either injected into the container as environment variables or used as credentials for authentication into the extender, volume, datastore, or messaging resource at deploy time. If the resource is deployed using a Recipe, the secrets are securely passed as outputs to Radius by the Recipe for use in provisioning and deploying the resource. ## Key investments @@ -379,6 +379,10 @@ Add the ability for developers to reference values from their `Applications.Core Add the ability for developers to specify the `Applications.Core/secretStores` resource as a parameter of the `object` type to the Bicep resource that requires the secret so that secrets can be passed as parameters into a Radius Bicep resource. +### Feature 5: Add functionality to reference `Applications.Core/secretStores` in Recipes + +Add the ability for operators to reference values from their `Applications.Core/secretStores` resources in their Recipe's `output` object so that secrets can be securely passed as outputs to Radius that can be used in provisioning and deploying the resource using the Recipe. + ## Key dependencies and risks From 7c6543cacd75b47717cd29d8dfcc7b09d1793702 Mon Sep 17 00:00:00 2001 From: Will Tsai <28876888+willtsai@users.noreply.github.com> Date: Fri, 1 Nov 2024 15:34:36 -0700 Subject: [PATCH 09/10] address feedback Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com> --- resources/2024-07-secretstore-feature-spec.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/resources/2024-07-secretstore-feature-spec.md b/resources/2024-07-secretstore-feature-spec.md index 472d027d..ca57aeff 100644 --- a/resources/2024-07-secretstore-feature-spec.md +++ b/resources/2024-07-secretstore-feature-spec.md @@ -414,4 +414,4 @@ Add the ability for operators to reference values from their `Applications.Core/ - Discussion around whether `Applications.Core/secretStores` is right, specifically whether it should be part of `Applications.Core` or whether it should be part of UCP (something like `System.Resources/secretStores`) -- *this is a larger discussion beyond the scope of this particular feature spec* - Scenario that allows for secrets to be passed as parameters into a Radius Bicep resource is missing -- *this scenario was added* - Need scenarios for referencing `Applications.Core/secretStores` in Radius Recipes -- *this scenario was added* -- Add more information on customers bringing in their own secrets, secrets stores resource currently supporting only k8s secrets -- TODO \ No newline at end of file +- Add more information on customers bringing in their own secrets, secrets stores resource currently supporting only k8s secrets -- *addressed in the spec* \ No newline at end of file From 6a05f7e736e62070f9d9bca50cb1a9b2bec8aa35 Mon Sep 17 00:00:00 2001 From: Will Tsai <28876888+willtsai@users.noreply.github.com> Date: Fri, 1 Nov 2024 15:35:35 -0700 Subject: [PATCH 10/10] address feedback Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com> --- resources/2024-07-secretstore-feature-spec.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/resources/2024-07-secretstore-feature-spec.md b/resources/2024-07-secretstore-feature-spec.md index ca57aeff..2cd63df0 100644 --- a/resources/2024-07-secretstore-feature-spec.md +++ b/resources/2024-07-secretstore-feature-spec.md @@ -406,7 +406,7 @@ Add the ability for operators to reference values from their `Applications.Core/ ## Current state - Feature request tracking this scenario: https://github.com/radius-project/radius/issues/5520 -- Pull request (work in progress) for adding secretstore references into container env variables: https://github.com/radius-project/radius/pull/7744 +- Pull request (merged) for adding secretstore references into container env variables: https://github.com/radius-project/radius/pull/7744 ## Design Review Notes