[Security Hardening]: Amplify OIDC/IAM Role support for "Keyless" Initiator Authentication

[UfiairENE]

Description:

Current State & Problem

The current implementation of KMSSigner and its associated documentation, examples (e.g., examples/sign/main.go), and deployment guides (e.g., deployments/ecs/README.md) prioritize the use of static AWS credentials (AccessKeyID and SecretAccessKey).

While functional, this "Keys-First" approach creates a significant security risk:

1. Secret Sprawl: Long-lived keys are often accidentally committed to repositories or logged in CI/CD environments.

2. Infrastructure Overheard: The ECS deployment guide currently requires an init-secrets container and ephemeral volumes just to fetch and write credential files, increasing the attack surface.

3. Manual Management: Users are forced to manage key rotation manually rather than leveraging IAM provider-led automated rotation.

The Opportunity

The underlying AWS SDK v2 logic in pkg/client/kms_signer.go already supports the Default Credential Chain, but this "Keyless" capability is currently under-documented and under-utilized. By amplifying this feature, we can enable:

• CI/CD OIDC: Using role-to-assume in GitHub Actions or GitLab with zero stored secrets.

• Cloud-Native Identity: Support for ECS Task Roles and EKS (IRSA) without needing init containers to handle credential files.

• Secure Local Dev: Using aws sso login to authenticate without needing permanent local .aws/credentials files.

Proposed Enhancements

I propose a holistic update to move the project toward a "Keyless-by-Default" posture:

• pkg/client/kms_signer.go: Update the KMSSignerOptions struct docstrings to label static keys as "Legacy/Optional" and recommend OIDC/IAM Roles for production.

• examples/sign/main.go: Refactor the logic to check for aws.kms_key_id. If present, it should attempt to initialize the KMSSigner using the environment identity (Default Credential Chain), falling back to the LocalSigner only if no AWS config exists.

• deployments/ecs/README.md: Update the guide to show how to eliminate the init-secrets container by using the ECS Task Role directly, significantly simplifying the task definition.

• README.md & SECURITY.md: Update the "AWS KMS Signer" sections to place the IAM/OIDC example first and document "Identity-based" authentication as the gold standard for initiator security.

Impact

• Zero-Secret Footprint: Users can run mpcium in any identity-aware environment without ever creating a static IAM Access Key.

• Reduced Attack Surface: Eliminates the need for temporary credential files on disk volumes in ECS/Fargate.

• Auditability: Every transaction trigger is tied to a specific IAM Role identity in AWS CloudTrail.

---

I would like to work on this

I have analyzed the current KMSSigner implementation and identified the necessary documentation and example updates to amplify this "Keyless" workflow. Please assign this issue to me, and I will submit a PR shortly.

[anhthii]

Hi @UfiairENE,

Yes, you can skip AccessKeyID and SecretAccessKey. Those are only required when testing with LocalStack or when you explicitly want to use static credentials.

For normal usage (AWS, ECS, EKS, GitHub Actions OIDC, EC2, etc.), you can just assign an IAM role and rely on the AWS Default Credential Chain. In that case, you don’t need to pass any static credentials in the code.

So the LocalStack example can be simplified to:

kmsSigner, err := client.NewKMSSigner(types.EventInitiatorKeyTypeP256, client.KMSSignerOptions{
    Region:      "us-east-1",
    KeyID:       "48e76117-fd08-4dc0-bd10-b1c7d01de748",
})

Documentation update PR is welcome. Feel free to proceed with the changes.