feat(deployment): surface declared confidential compute config on the deployment view#3353
Merged
Merged
Conversation
… deployment view For deployments declaring a TEE type (services.<name>.params.tee in the stored SDL manifest): - show a Confidential Compute badge in the deployment sub-header (presence-driven, friendly CPU / CPU + GPU labels, declared-intent framing) - render the attestation sidecar's per-service resource carve-out (requested / sidecar / available) in the lease view, with a note when the declared budget is below the footprint - defensively keep the sidecar out of the lease-status service lists via one useLeaseStatus select chokepoint The feature self-gates on a declared params.tee, so non-CC deployments are unaffected.
Contributor
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughAdds TEE helpers and hooks, renders confidential-compute UI in deployment views, filters attestation sidecar data in lease queries, and expands the provider JWT scope. ChangesConfidential compute display and attestation flow
Estimated code review effort🎯 4 (Complex) | ⏱️ ~50 minutes Suggested reviewers
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #3353 +/- ##
==========================================
- Coverage 69.63% 69.10% -0.54%
==========================================
Files 1087 1048 -39
Lines 26672 25664 -1008
Branches 6415 6249 -166
==========================================
- Hits 18574 17736 -838
+ Misses 7111 6953 -158
+ Partials 987 975 -12
*This pull request uses carry forward flags. Click here to find out more.
🚀 New features to boost your workflow:
|
…in group attribute Confidential Compute is declared on-chain as a group placement requirement (group_spec.requirements.attributes "tee/type" = cpu | cpu-gpu) so only TEE-capable providers can bid and match — it is not a localStorage-only value as the initial implementation assumed. Reading the stored SDL manifest's params.tee meant the badge and carve-out would never render for a real CC deployment (e.g. one created from the CLI). Re-base on data deploy-web already loads: badge = distinct tee/type across deployment.groups; per-pod carve-out = one entry per lease.group group_spec.resources unit (the attestation sidecar is injected into every pod of a CC group), labelled by resource composition since on-chain groups carry no service names, with the replica count noted. Drop the js-yaml/params.tee manifest path (getDeclaredTeeTypesFromYaml, getServiceTeeType, getServiceComputeResources, getTeeServiceCarveouts). Keep the sidecar carve-out math and constants, omitAttestationSidecar, the badge, labels/tooltip and the no-feature-flag behaviour.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@apps/deploy-web/src/utils/confidentialCompute.ts`:
- Around line 41-47: `parseIntegerVal` currently uses `parseInt`, which accepts
numeric prefixes and lets malformed values like suffixed strings slip through as
valid counts. Update `parseIntegerVal` in `confidentialCompute.ts` to only
accept exact integer strings by validating the whole string before converting,
while keeping the existing `number` and non-string handling unchanged. Use the
`parseIntegerVal` helper itself as the place to enforce this stricter parsing so
invalid on-chain resource values are returned as undefined.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: c5c2fb43-4c79-4cbf-9086-70013dae76c1
📒 Files selected for processing (6)
apps/deploy-web/src/components/deployments/ConfidentialComputeResources.spec.tsxapps/deploy-web/src/components/deployments/ConfidentialComputeResources.tsxapps/deploy-web/src/components/deployments/DeploymentDetail.tsxapps/deploy-web/src/components/deployments/LeaseRow.tsxapps/deploy-web/src/utils/confidentialCompute.spec.tsapps/deploy-web/src/utils/confidentialCompute.ts
🚧 Files skipped from review as they are similar to previous changes (3)
- apps/deploy-web/src/components/deployments/ConfidentialComputeResources.spec.tsx
- apps/deploy-web/src/components/deployments/DeploymentDetail.tsx
- apps/deploy-web/src/components/deployments/ConfidentialComputeResources.tsx
Wrap the root-level getDeclaredTeeTypes / getTeeResourceCarveouts calls in useDeclaredTeeTypes / useTeeResourceCarveouts hooks so DeploymentDetail and LeaseRow call a hook at the render root rather than a bare memoized util, following the established pattern (cf. useTrialDeploymentTimeRemaining). The pure functions stay in confidentialCompute.ts with their unit tests; the hooks own the useMemo. No behaviour change.
stalniy
approved these changes
Jun 24, 2026
This was referenced Jun 24, 2026
baktun14
added a commit
to akash-network/console-air
that referenced
this pull request
Jun 25, 2026
… view (#37) Port akash-network/console#3353 (upstream CON-451) into the self-custody fork. Read the on-chain `tee/type` group placement attribute and surface Confidential Compute on the deployment detail view, sourced from chain so it works for any client (Console/CLI/SDK). - Confidential Compute badge in the deployment sub-header, per declared TEE type - per-pod Requested -> attestation sidecar -> available carve-out in the lease row, mirroring the provider sidecar footprint (akash-network/provider#396) - defensive omitAttestationSidecar chokepoint on useLeaseStatus (passthrough today) No managed-wallet/JWT coupling: the upstream global-scope `attestation` change and its #3360 revert are a no-op here (console-air's JWT is a blockchain-down fallback). Data-gated; no feature flag, matching the upstream merged behavior.
domhhv
pushed a commit
to domhhv/akash-network-console
that referenced
this pull request
Jun 27, 2026
…kash-network#3360) PR akash-network#3353 added "attestation" to the global managed-wallet provider JWT scope unconditionally. Field and non-TEE providers validate the scope against an enum that does not include "attestation" and reject the entire JWT with "JWT has invalid claims", so manifest sends fail for every managed deployment and the deployment never goes active. Revert the global scope back to the base set. The attestation scope is only needed to call the provider attestationQuote endpoint, which has no consumer on this token; it moves to a per-provider granular token for confidential compute attestation-evidence downloads (akash-network#3359).
domhhv
pushed a commit
to domhhv/akash-network-console
that referenced
this pull request
Jun 27, 2026
…ute leases (akash-network#3359) * fix(jwt): remove attestation from global managed-wallet token scope PR akash-network#3353 added "attestation" to the global managed-wallet provider JWT scope unconditionally. Field and non-TEE providers validate the scope against an enum that does not include "attestation" and reject the entire JWT with "JWT has invalid claims", so manifest sends fail for every managed deployment and the deployment never goes active. Revert the global scope back to the base set. The attestation scope is only needed to call the provider attestationQuote endpoint, which has no consumer on this token; it moves to a per-provider granular token for confidential compute attestation-evidence downloads (akash-network#3359). * feat(deployment): download attestation evidence for confidential compute leases Surface a download for a running Confidential Compute lease's hardware-signed attestation evidence (AEP-83 §5). A fresh 64-byte nonce is sent per request so the returned evidence is bound to that request; the preview distinguishes the single CPU report from per-GPU reports and saves the full bundle as JSON. Fetched over the existing JWT provider-proxy path (the managed-wallet token carries the `attestation` scope) — front-end only, no backend change. Gated behind the new `ui_confidential_compute` flag and only shown for running deployments whose on-chain group declares a tee/type. Part of CON-540 * refactor(deployment): guard attestation download on resolved provider and extract report label * feat(deployment): mint per-provider token for attestation evidence download The provider attestationQuote endpoint requires the `attestation` JWT scope. akash-network#3360 removed that scope from the shared global managed-wallet token because non-TEE providers reject it. Add useProviderJwt.generateScopedProviderToken to mint an ephemeral, single-provider granular token carrying only `attestation`, and use it from useAttestationQuoteMutation instead of the global token. Only TEE-capable providers accept the scope, and the download trigger already renders solely for confidential-compute leases, so the scoped token is requested only where the provider accepts it. Ref CON-575 * fix(deployment): bind attestation evidence to its nonce and time-bound the fetch Return the per-request nonce alongside the quote and include it in the downloaded bundle so the evidence can be verified for freshness against the hardware-signed report_data. Give the attestation quote fetch a finite 60s timeout so a stalled provider surfaces the modal's error/retry UI instead of hanging in a pending state. Addresses CodeRabbit review feedback on PR akash-network#3359. * refactor(deployment): drop ui_confidential_compute flag from attestation download The download already only renders for live leases whose on-chain group declares a TEE type, so it never surfaces for non-Confidential-Compute deployments. The feature flag was redundant.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Closes CON-451.
After deploying a Confidential Compute (TEE) workload, a tenant should be able to confirm from the deployment detail view that a TEE was actually requested, understand the resource slice the provider's attestation sidecar reserves, and not be confused by that sidecar. This is the deploy-web counterpart to the already-merged backend support (#3344 / CON-463).
The declared TEE type is recorded on-chain as a group placement requirement:
group_spec.requirements.attributescarries atee/typeattribute (cpu|cpu-gpu) so only TEE-capable providers can bid and match. deploy-web already loads this for every deployment, so the surface reads it directly from the chain — it works for deployments created from any client (Console, CLI, SDK), not only those whose SDL manifest happens to be in this browser's localStorage.What
For deployments whose groups declare an on-chain
tee/type:Confidential Compute (CPU)/(CPU + GPU)badge in the deployment sub-header, shown whenever any group declarestee/type(distinct types across groups listed in the tooltip for mixed deployments). The tooltip frames it as declared intent whose confidentiality depends on the provider honoring the request and passing attestation — not a verified runtime guarantee.Requested → Attestation sidecar → Available to your container, one entry pergroup_spec.resourcesunit (the sidecar is injected into every pod of a CC group), replicating the provider's subtraction + floors (sidecar limits: 100m CPU, 64Mi/128Mi memory; floors 10m / 16Mi — matching feat: confidential compute provider#396). On-chain groups carry no service names, so each unit is labelled by its resource composition (e.g.8 CPU · 32 GiB · 1 GPU) when a lease declares more than one, with the replica count noted. A note appears when the declared budget is at/below the sidecar footprint (so the floored values aren't misread as broken arithmetic). Billing is unchanged — the slice comes out of the container, not the bill.select: omitAttestationSidecarchokepoint onuseLeaseStatus. The sidecar is a pod container today (never aleaseStatus.serviceskey), so this is a documented passthrough that guards the pre-GA provider contract for the status/logs/shell selectors.Notes for reviewers:
tee/type, so non-CC deployments are completely unaffected. Trivially reversible by wrapping the new UI inuseFlag("ui_confidential_compute").snp-gpu), so the badge can be verified end-to-end against a realcpu-gpudeployment — this supersedes the earlier CON-459 "no CC provider yet" assumption.Summary by CodeRabbit
Release Notes
New Features
Bug Fixes
Tests
Chores