A workload identity evidence partner is the firm you hire when the federation cutover is underway and the proof is still a slide. The before state is a census of access keys, static secrets, and role trusts that accept more than the workload that should assume them. The after state is the trust document that replaced those keys, plus the CloudTrail event that shows the new role was actually assumed. Rutagon files both samples in the GRC you already run. We are not your auditor. We make the sample answerable.
The buyer is usually a CTO who already decided long-lived keys have to go, and a compliance lead who has to show the cutover instead of describe it. A staff engineer can open IAM and point at a role. That is not a census. A census is every IAM user with an active access key, every secret the pipeline still injects, and every trust policy whose principal is broader than the identity provider you named. The partner's job is to produce that list before the cutover and the matching list after it, then leave a record a reviewer can open without reconstructing chat history.
What the before census actually contains
The before census is an export, not a screenshot. For each access key we record the account, the IAM user or the system that holds the key, the key id, the status, and the last-used timestamp from the credential report. A key that shows no use is still a key. We do not drop it because it looks idle. Idle keys are how a contractor keeps a path nobody remembers granting.
Role trusts are the second half of the same census. A trust that allows sts:AssumeRole from any principal in the account, or from an account root with no condition, is a standing credential even when nobody stored an access key. We sample the trust policy, hash it, and store the hash next to the role ARN. The sample the reviewer sees later is that hash plus the policy text, not a memory of what the policy used to say.
CI is in the census. A pipeline variable that holds a cloud credential, a deploy key that can push to the infrastructure repository, and a long-lived token on the source host are the same class of finding as an IAM access key. The workload identity federation migration is the cutover those findings feed. This engagement is the evidence around that cutover: the list before, the trust after, and the filing.
We also mark keys we will not touch in the first wave. A break-glass key, if you truly have one, stays on a named owner with an expiry the record stores. "We might need it" is not an owner. A key without an owner stays on the open list. Sandbox accounts can sit on a second list. Mixing them into the production census makes the sample dishonest, so every row carries the account id.
Role-trust samples after the cutover
The after sample is the trust policy that replaced the key. The role has no access keys of its own. The principal is the OIDC provider in the same account, which is where IAM expects that provider to live. The condition pins the audience to the value you registered, and it pins the subject to the repository, environment, or workload identity allowed to assume the role. A trust that only checks the issuer is not a finished cutover. Anyone who can mint a token from that issuer would pass.
AWS describes how an OIDC provider is created, and which claims the token must carry, in the OIDC identity provider documentation. We use that shape. We do not invent a private claim and then forget to put it in the condition. If the identity provider puts the audience in azp as well as aud, STS treats azp as the audience. The sample notes which claim we conditioned on, so a later token change does not silently widen the role.
A second pattern shows up when the workload is not the CI host. A service account in another cloud can assume an AWS role the same way: a federated principal, a subject bound to that account, and no long-lived AWS key on the caller. That pattern is the one we describe in cross-cloud identity federation. The evidence shape does not change. Before: the key. After: the trust. The CloudTrail event is AssumeRoleWithWebIdentity, and we store the event id, the event time, and enough of the identity to show the subject.
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::ACCOUNT:oidc-provider/token.actions.githubusercontent.com"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
},
"StringLike": {
"token.actions.githubusercontent.com:sub": "repo:ORG/REPO:environment:production"
}
}
}
The snippet is the shape of the after sample, with the account and repository left as placeholders. We store the real document from the account, not this sketch. The hash of the applied trust is what the GRC record points at. If someone edits the trust after we file it, the next sample's hash will not match, and the record stays open.
What a workload identity evidence partner files
Each cutover record has a stable set of fields. The role ARN. The before key id and its disabled or deleted status. The after trust hash. The approver, who is not the person who wrote the trust. The CloudTrail event id of a successful assume with the expected subject. The ticket id that came back from the GRC you already run. A record missing the assume event is not closed. A green pipeline icon is not evidence that the old key is dead.
We disable the old key before we delete it, and we watch for access-key use in a short window after disable. Use after disable means something still holds the secret. The record stays open and names the caller if CloudTrail has it. Deleting a key that is still in use is how you learn about the job you forgot, at the worst time. The partner's job is to surface that caller while the key is only disabled.
The permission policy on the role is in the sample too, not only the trust. A perfect subject condition on a role that still has AdministratorAccess is a finished identity cutover and an unfinished privilege problem. We attach the policy names and a hash of the policy documents. We do not quietly expand the engagement into a full access review unless you ask. The record should show what the role can do on the day of the cutover so the reviewer is not surprised later.
What we do not deliver is a policy PDF, a login for your auditor, or a claim that your program is certified. Security automation is the build. The GRC you already run keeps the ticket. Rutagon's own pipelines follow the same rule we ask of the record: an OIDC assume, and no long-lived key on the apply role. That is engineering practice. It is not an attestation you can borrow.
How to judge the engagement
Ask for the before census on one account before you sign a long statement of work. The output should be rows, not a narrative. If the firm cannot show last-used, status, and the trust hash, they are going to interview your team and call the interview an audit. Interviews drift. Exports do not.
Ask what happens to a key the application still uses. The answer should be a named caller, a disable window, and an open record. The answer should not be "we rotated it." Rotation leaves a new long-lived secret in the same place. The cutover replaces the secret with a trust. Rotation is the trap we are not selling.
Ask where the after sample lives after the engagement ends. If the answer is a shared drive, the next reviewer will not find it. The ticket id in the GRC you already run is the lookup. We keep the JSON stable so the next window is the same export, not a new template someone has to learn.
The engagement is sized to the census, not to a transformation program. A single production account with a handful of pipeline roles is a bounded cutover. An organization with keys in every member account is the same record repeated, with the account id on the row. The buyer is the person who has to show the keys are gone.
A useful partner will also say what they will not touch. Customer-managed applications with their own password table are a different system. We will list them if the census finds a cloud key inside them. We will not pretend a role trust fixes an application password. That boundary keeps the sample honest. The compliance lead can forward the record to the CTO without translating a metaphor into a control.
If two people must approve the trust, the record stores both, and it stores that the author is neither of them. A pipeline role that applies its own trust change does not count as the approver. Someone accountable approved the digest of the trust before it was applied. That is the same separation we use on infrastructure changes, applied here to the identity cutover.
Frequently Asked Questions
What does a workload identity evidence partner hand you at the end?
A before census of access keys and overly broad trusts, an after sample of each role trust with its hash, and a CloudTrail event id for a successful federated assume. Those fields are filed in the GRC you already run, with the ticket id stored on the record. A narrative without the key status and the trust hash is not the deliverable.
Why disable the old key instead of deleting it immediately?
Disable keeps the key from working while CloudTrail can still show a caller that tries it. If something uses the key after disable, the record stays open and names that caller when the log has it. Deletion comes after that window is quiet. Deleting first turns the forgotten job into an outage.
Does the trust only need the identity provider, or also a subject condition?
The provider alone is not enough. The condition should pin the audience and the subject to the repository, environment, or workload that may assume the role. We record which claim we used, including the case where the token carries the audience in a claim STS will treat as the audience. A later edit that drops the subject condition fails the next hash check.
Where does a workload outside AWS fit this evidence?
A service account outside AWS can assume a role with the same evidence shape: no long-lived AWS key, a federated principal, a subject bound to that workload, and an assume event in CloudTrail. The before row is still the key or the static secret. The after row is still the trust hash. The account id on the row keeps that caller from being filed against the wrong account.
Will this engagement certify the company?
No. We file the cutover sample in the GRC you already run. We do not issue an attestation, and we do not replace your auditor. The record is there so a sample request is a lookup.
Book a technical call about the census and the filing. Contact Rutagon at rutagon.com/contact, 907-841-8407, or contact@rutagon.com.