Skip to content

Conversation

@boxofrad
Copy link
Contributor

This is a spike of a possible solution for #53711.

How it works

Rather than depending on *authclient.Client or client.Client directly, we now pass around our own wrapper struct. If the bot identity service initialization fails but there is an old identity on-disk, it'll return "successfully" but the client wrapper will be rigged to return an error on each RPC.

This effectively allows tbot to run in a "degraded" state without a functioning API client, while the bot identity service's Run method retries the initialization in the background.

The roles anywhere service now writes its SVID to a "cache" destination (in-memory by default, but can be configured to on-disk) and if the client returns an error because initialization fails, it'll fall back to using the cached SVID for the exchange.

I've tested this manually by running tbot once with the following configuration, killing it, stopping the auth server, restarting tbot, and then restarting the auth server.

version: v2
proxy_server: <address>
onboarding:
  join_method: token
  token: <token>
storage:
  type: directory
  path: /Users/dan/Desktop/tbot/internal
services:
  - type: workload-identity-aws-roles-anywhere
    destination:
      type: directory
      path: /Users/dan/Desktop/tbot/aws-ra
    cache:
      type: directory
      path: /Users/dan/Desktop/tbot/aws-ra-cache
    role_arn: <arn>
    profile_arn:  <arn>
    trust_anchor_arn: <arn>
    region: eu-west-2
    selector:
      name: aws-ra-workload-identity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants