Skip to content

Conversation

@vishwahiremat
Copy link
Contributor

No description provided.

Signed-off-by: Vishwanath Hiremath <vhiremath@microsoft.com>
@vishwahiremat vishwahiremat requested review from a team as code owners January 7, 2026 17:50
Signed-off-by: Vishwanath Hiremath <vhiremath@microsoft.com>
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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. prevention of recipe changes with malicious intent, 2. prevent recipe changes from breaking infrastructure inadvertantly. Is this correct?

Copy link
Member

@brooke-hamilton brooke-hamilton left a 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?

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.
Copy link
Contributor

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

Copy link
Contributor

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.

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.
Copy link
Contributor

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'?

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
Copy link
Contributor

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.
Copy link
Contributor

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.
Copy link
Member

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
Copy link
Contributor

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?

- 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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.
Copy link
Contributor

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.


```
#### 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.
Copy link
Member

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 digest and ignore the tag resolution (strong immutability, drift detection becomes a warning-only or not done at all).



### CLI Design (if applicable)
Adding digest details to `rad recipe-pack show` command.
Copy link
Contributor

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
Copy link
Member

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.

Copy link
Contributor Author

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
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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.
Copy link
Contributor

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?

Copy link
Contributor Author

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.


```
#### 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.
Copy link
Contributor

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.
Copy link
Contributor

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>
Signed-off-by: Vishwanath Hiremath <vhiremath@microsoft.com>
Copy link
Member

@brooke-hamilton brooke-hamilton left a 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
Copy link
Contributor

@nithyatsu nithyatsu Jan 14, 2026

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'
Copy link
Contributor

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
Copy link
Contributor

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.

Copy link
Contributor

@kachawla kachawla Jan 14, 2026

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

9 participants