-
Notifications
You must be signed in to change notification settings - Fork 18
Enhance recipe-engine to support digests #134
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Enhance recipe-engine to support digests #134
Conversation
Signed-off-by: Vishwanath Hiremath <vhiremath@microsoft.com>
|
|
||
| #### User story 2 | ||
| As a user of Radius recipes, I want Radius to execute the same recipe artifact that I originally published and intended during deployment, so that hidden registry changes cannot cause unexpected infrastructure behavior. | ||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- prevention of recipe changes with malicious intent, 2. prevent recipe changes from breaking infrastructure inadvertantly. Is this correct?
brooke-hamilton
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about using Spec Kit for this spec?
recipe/2025-12-recipe-digest.md
Outdated
| Terraform recipes require source‑specific immutability rules that align with Terraform’s supported module sources. However, this can be achieved for most module sources, but plain HTTPS or S3 needs explicit versioning or checksums. | ||
|
|
||
| - **Git/Mercurial Based Modules** : Pin module sources using immutable commit SHAs (ref=<commit‑sha>) | ||
| - **Terraform Registry Modules** : Registry enforces immutability of published versions. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would we add more details here, such as a terraform documentation link that captures how tf configs can be used in a secure way
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1. Also need to specify what would happen if the user provides digest for a Terraform Recipe in the pack.
recipe/2025-12-recipe-digest.md
Outdated
| As a platform engineer, I want to pin a recipe to an immutable digest when I register it in a recipe pack, so that any deployment using that recipe executes exactly the artifact I reviewed and approved. | ||
|
|
||
| #### User story 2 | ||
| As a user of Radius recipes, I want Radius to execute the same recipe artifact that I originally published and intended during deployment, so that hidden registry changes cannot cause unexpected infrastructure behavior. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we expand/give example of 'hidden registry changes'?
recipe/2025-12-recipe-digest.md
Outdated
| The core idea is : | ||
| - A recipe is registered with both a tag and a digest | ||
| - The digest represents the exact recipe artifact that is allowed to execute | ||
| - During deployment, recipes are pulled by digest, not by tag |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if a digest is supplied, does the tag become optional?
| - The absence of an explicit digest in the recipe definition obscures which artifact was intended at authoring time. | ||
|
|
||
| #### Proposed Option | ||
| Option 1 is recommended. While Option 2 offers a slightly smoother authoring experience, it can result in the recipe pack being bound to a different artifact than the one originally published. Option 1 requires the digest to be explicitly provided by the user, making the intended recipe artifact clear, stable, and auditable. The additional manual step is acceptable for infrastructure recipes and aligns with established digest‑pinning practices used for OCI artifacts. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed. And since providing the digest is optional anyway, the additional manual work is not forced upon the user.
| - Maintain backward compatibility for existing recipes that do not specify a digest. | ||
|
|
||
| ### Non goals | ||
| - No automatic patching of running apps if digests change; updates are explicit via recipe pack changes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: this is phrased as a goal rather than as a non-goal
| Disadvantages: | ||
| - **Manual step required**: Users must copy the digest from publish output into the recipe pack definition. | ||
|
|
||
| ##### Option 2: Controller‑Computed Digest During Registration |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
would there be advantages to compute and store the digest anyway, even if users don't want to specify the use of digests?
recipe/2025-12-recipe-digest.md
Outdated
| - The digest represents the exact recipe artifact that is allowed to execute | ||
| - During deployment, recipes are pulled by digest, not by tag | ||
|
|
||
| This guarantees that the infrastructure deployed by Radius is always derived from the same recipe artifact that was originally published and registered.and persists the new digest. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| This guarantees that the infrastructure deployed by Radius is always derived from the same recipe artifact that was originally published and registered.and persists the new digest. | |
| This guarantees that the infrastructure deployed by Radius is always derived from the same recipe artifact that was originally published and registered, and persists the new digest. |
| - The absence of an explicit digest in the recipe definition obscures which artifact was intended at authoring time. | ||
|
|
||
| #### Proposed Option | ||
| Option 1 is recommended. While Option 2 offers a slightly smoother authoring experience, it can result in the recipe pack being bound to a different artifact than the one originally published. Option 1 requires the digest to be explicitly provided by the user, making the intended recipe artifact clear, stable, and auditable. The additional manual step is acceptable for infrastructure recipes and aligns with established digest‑pinning practices used for OCI artifacts. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think option 1 is fine because it's an "opt-in" security feature.
recipe/2025-12-recipe-digest.md
Outdated
|
|
||
| ``` | ||
| #### Registering a recipe pack | ||
| When registering a recipe pack, users can optionally specify the digest of the recipe artifact. When provided, the digest becomes the authoritative identifier used for deployment. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Clarify what "authoritative" means (tag vs digest behavior). i.e.
- strict: if digest is set, deployment fails if recipeLocation tag doesn't currently resolve to the same digest (strong drift detection).
- digest-authoritative: always pull
digestand ignore the tag resolution (strong immutability, drift detection becomes a warning-only or not done at all).
recipe/2025-12-recipe-digest.md
Outdated
|
|
||
|
|
||
| ### CLI Design (if applicable) | ||
| Adding digest details to `rad recipe-pack show` command. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
and also to the recipe publish commands too, right?
| This proposal introduces a consistent approach to **recipe source integrity**, ensuring that recipes executed during deployment are identical to those originally intended. By validating artifact identity deployment time, Radius can detect unexpected changes and prevent execution of modified content. | ||
|
|
||
|
|
||
| ## Terms and definitions |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Define the expected digest format/validation. Add a short note specifying sha256:<64 hex> and whether other algorithms are allowed; also whether validation happens at registration time, deploy time, or both.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
validation happens only at deploy time.
| ``` | ||
|
|
||
|
|
||
| ### Error Handling |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if there is a mismatch between the provided tag and digest? Does the digest take precedence, or would we error out?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
removed the digest filed in the updated design.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
agree with the updated design, much better
|
|
||
| Terraform is different as recipes are executed by invoking `terraform init` and `terraform apply`, and Terraform itself provides built‑in integrity mechanisms: | ||
| - Git sources can be pinned to immutable commit SHAs. | ||
| - Terraform Registry modules are versioned and protected by checksums recorded in .terraform.lock.hcl. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the user experience for Terraform recipe deployment if the terraform registry module version is mutated in place?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
terraform registry modules are mutable, users should enable immutable github releases/tags to achieve immutability for modules.
recipe/2025-12-recipe-digest.md
Outdated
|
|
||
| ``` | ||
| #### Registering a recipe pack | ||
| When registering a recipe pack, users can optionally specify the digest of the recipe artifact. When provided, the digest becomes the authoritative identifier used for deployment. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should it be a required property?
| ##### Option 1: User‑Provided Digest at Registration Time | ||
| In this approach, the digest is explicitly supplied by the user when creating or updating a recipe pack. The digest is typically obtained from the output of the recipe publish command and added as part of the recipe definition. | ||
| Workflow | ||
| - The user publishes a Bicep recipe to an OCI registry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we making an assumption that bicep sources will always support a digest?
Signed-off-by: Vishwanath Hiremath <vhiremath@microsoft.com>
brooke-hamilton
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should do this spec as a Spec Kit feature. It would be fairly simple to use this document as input to /speckit.specify.
| - Update authoring guide: copy digest from publish output into recipe pack. | ||
| - Add docs for terraform recipe integrity. | ||
|
|
||
| ## Open Questions |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would we automaticaly detect if the url has a digest or tag , and take action appropritely so that digest remains optional? How do we detect it?
| recipes: { | ||
| 'Radius.Cache/redis': { | ||
| recipeKind: 'bicep' | ||
| + recipeLocation: 'vishwaradius.azurecr.io/redis@sha256:c6a1…eabb' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I much prefer this to requiring a separate recipeDigest field
|
|
||
| Because OCI digests are immutable, this pull operation deterministically retrieves the exact recipe artifact that was originally published and registered. | ||
|
|
||
| ### Integrity Enforcement for Terraform Recipes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
General guidance for Terraform - if the recipe source supports digests (e.g. git source with specific hash in the URI) then Radius should be able to support it without "getting in the way". If the source does not support digests, it is not the responsibility for Radius to build that funcationality.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1. I think we should apply same guidance to bicep since there is no guarantee that all future bicep sources will always support a digest.
No description provided.