Typo in ECS PKCS#11 sample: secret ID cupassowrd should be cupassword (breaks HSM auth in the sample)

Summary

In cloudhsm-base/pkcs11-5.0-sample/run.sh, the Secrets Manager secret ID is misspelled as cupassowrd (should be
cupassword). As a result, the ECS sample container fails to retrieve the crypto-user credentials, and the AES-GCM
sample operation runs with an empty PIN and cannot authenticate to the CloudHSM cluster.

Location

File: cloudhsm-base/pkcs11-5.0-sample/run.sh (branch main), lines 9–10:

HSM_USER=$(aws secretsmanager get-secret-value --secret-id '/cloudhsm/workshop/cupassowrd' --query SecretString
--output text | jq .username -r)
HSM_PASSWORD=$(aws secretsmanager get-secret-value --secret-id '/cloudhsm/workshop/cupassowrd' --query SecretString
--output text | jq .password -r)

The secret ID /cloudhsm/workshop/cupassowrd has the letters w and r transposed. The secret actually created by
CloudhsmBaseStack (logical ID cuPasswordE6C54B6C) is /cloudhsm/workshop/cupassword.

Impact

- Both get-secret-value calls fail with AccessDeniedException (the misspelled secret does not exist; the task role is
scoped to the correctly-named secret).
- HSM_USER and HSM_PASSWORD are therefore empty, so the loop runs aes_gcm --pin :, which cannot authenticate to the
HSM.
- Observable behavior: ECS tasks appear healthy and the CloudHSM SDK connects to the cluster, but the AES-GCM
operation the sample is meant to demonstrate never succeeds. Every task logs the following in CloudWatch log group
/ecs/cloudhsm-sample:

An error occurred (AccessDeniedException) when calling the GetSecretValue operation:
... is not authorized to perform: secretsmanager:GetSecretValue on resource:
/cloudhsm/workshop/cupassowrd ...

- Severity: functional bug in the sample, but non-blocking for the "Scale the Service" learning objective (tasks still
start and connect). Low urgency; should be corrected in a future revision.

Fix

Correct the secret ID on both lines:

HSM_USER=$(aws secretsmanager get-secret-value --secret-id '/cloudhsm/workshop/cupassword' --query SecretString
--output text | jq .username -r)
HSM_PASSWORD=$(aws secretsmanager get-secret-value --secret-id '/cloudhsm/workshop/cupassword' --query SecretString
--output text | jq .password -r)

Then rebuild/redeploy the sample container image via the CDK pipeline.

Additional verification suggested

Confirm the ECS task role (EcsTestStack-taskRole...) grants secretsmanager:GetSecretValue on the correctly-named
secret /cloudhsm/workshop/cupassword.

Open cloudhsm-base/pkcs11-5.0-sample/run.sh and inspect lines 9–10, then compare the referenced secret with the one created by CloudhsmBaseStack. Correct both secret IDs, rebuild and redeploy the sample container through the CDK pipeline, and verify the ECS task role and AES-GCM operation use the correctly named secret.

Written by the indexing model from the issue text.