AWS Credentials

AWS Credentials

An aws deploy environment in the admin console collects an access key pair. This page says where each value comes from and what shape it has.

Precaución

Check which target actually deploys before you create a key. In the admin console today only the greentic_cloud target has a working deploy pipeline; an aws environment stores what you enter but a deploy attempt is refused with “this target’s deploy pipeline has been retired”. Create the key when you have confirmed your deployment lane needs it — for example a gtc CLI deploy from your own machine, which reads the same environment variables. See Cloud Deploy Environments.

The fields

Field	Environment variable	Shape
Access key ID	AWS_ACCESS_KEY_ID	20 uppercase alphanumeric characters, beginning AKIA for a long-lived key or ASIA for a temporary one
Secret access key	AWS_SECRET_ACCESS_KEY	40 characters, mixed case with + and /
Session token	AWS_SESSION_TOKEN	long, opaque; only for temporary credentials

The region is not asked for here — the deployer supplies its own default.

Nota

A session token belongs with an ASIA… access key ID. If your access key starts with AKIA you have a long-lived key and the session token field stays empty; a leftover token from an earlier session makes an otherwise valid key fail to authenticate.

Creating an access key pair

1. Create an IAM user for the deploy, rather than reusing a human’s credentials. In the AWS console go to IAM → Users → Create user, and do not grant it console access.

2. Attach a policy that covers what your deploy actually does — see Which permissions? below.

3. Open the user → Security credentials → Create access key, and choose the Application running outside AWS use case.

4. Copy both halves now. AWS shows the secret access key exactly once; if you lose it you must create a new key, not recover this one.

Or with the CLI:

aws iam create-access-key --user-name greentic-deployer

The response carries AccessKeyId and SecretAccessKey. Nothing prints it again.

Temporary credentials

If your organisation forbids long-lived keys, assume a role and use the three-part result:

aws sts assume-role \
  --role-arn arn:aws:iam::123456789012:role/GreenticDeployer \
  --role-session-name greentic

Credentials.AccessKeyId, Credentials.SecretAccessKey and Credentials.SessionToken map onto the three fields. They expire — an hour by default — so a stored deploy credential will stop working and must be refreshed.

Which permissions?

Greentic does not publish a minimum IAM policy for an AWS deploy, and this page will not invent one: the AWS deploy lineage in the admin console has been retired, so there is no live pipeline whose calls could be enumerated into a policy that is actually correct.

If you are deploying to AWS through a route that does work for you, derive the policy from that route rather than from a list here — run the deploy with a permissive role first, read CloudTrail for the actions it made, and narrow to those.

Alternatives to a key pair

The deployer recognises two other credential styles. Neither is offered by the admin console’s environment form, which collects the access key pair only, but both work when you run a deploy yourself with the environment set:

• Named profile — set AWS_PROFILE (or AWS_DEFAULT_PROFILE) to a profile in ~/.aws/credentials. Nothing secret leaves your machine.
• Web identity — set AWS_WEB_IDENTITY_TOKEN_FILE to the path of a projected OIDC token, and optionally AWS_ROLE_ARN. This is the shape a CI runner or an EKS pod uses, and it needs no stored secret at all.

Rotating and revoking

Access keys are revoked at the source, not in Greentic:

aws iam update-access-key --user-name greentic-deployer \
  --access-key-id AKIA... --status Inactive
aws iam delete-access-key --user-name greentic-deployer --access-key-id AKIA...

Deactivate first and watch for failures before deleting — a key you delete cannot be restored.

See also

• Cloud Deploy Environments
• Google Cloud Credentials
• Azure Credentials