Specify join method for static tokens.

[giriparus]

I am creating a static token to be used by my CI/CD pipeline. I know it is discouraged but I need a reusable token since teleport does not have a bitbucket pipelines integration.

So to configure my bot to access resources in my teleport cluster, I could specify role and token name as below :

auth_service:
  enabled: true
  cluster_name: teleport.example.com # update to your own public domain
  listen_addr: 0.0.0.0:3025
  proxy_listener_mode: multiplex
  tokens:
    - "bot:mybottoken"

But when I have my bot join the cluster using this, it throws an error saying invalid join method.
Upon inspecting the tokens. Static tokens do not have a join method at all. It's an empty string.

Can anyone please help me with a way to configure the join method for static tokens?

[zmb3]

Your auth service config looks fine. What does your tbot configuration look like?

[webvictim]

I think you want an onboarding config in your /etc/tbot.yaml like this:

onboarding:
  token: mybottoken
  join_method: token

[giriparus]

Doesn't the --join-method flag in tbot start command do the same thing? Because I tried it and the same error persists.

[giriparus]

Thank you for your quick responses @zmb3 and @webvictim.

As of now I was creating the tbot using CLI like so :-

tbot start
--destination-dir=./tbot-user
--token=mybottoken
--proxy-server=teleport.example.com:443
--join-method=token &

This is output of tctl get tokens for "mybottoken" created by the above auth service ( the join method here is "" and not editable )

kind: token
metadata:
expires: "1970-01-01T00:00:00Z"
name: mybottoken
spec:
join_method: ""
roles:

• Bot
  version: v2

The error I get when I try to join using the tbot start command above is ERROR: unsupported join method "" for bot

I believe @webvictim you're suggesting I use a config file to create the tbot with tbot configure and add the join method and token? I will try doing that and let you know if it works!

It might be important to note that I am trying to run this in a bitbucket pipeline so the tbot host is not a VM but a debian docker container which doesn't have systemd support.

In case the additional information provided in this reply has helped you to another approach or reinforced the same one, do let me know.

Thanks again!

[webvictim]

I tested this myself and can confirm it doesn't work. I get the same error: ERROR: unsupported join method "" for bot

The token isn't able to be looked up by name, which is a problem:

ubuntu@ip-172-31-30-140:~$ sudo tctl get token/mybottoken
ERROR: provisioning token(*******ken) not found

I'm checking with the Machine ID team to see whether this is an expected use case or not. My guess is that because Machine ID join tokens are technically single-use, the use case where a token is statically defined once in the config file and used multiple times is not supported. If this is the case, however, we should error when bot: tokens are set via the config file so folks don't get confused in future.

How to do this correctly

As per the docs (https://goteleport.com/docs/enroll-resources/machine-id/getting-started/#step-24-create-a-bot-user), the supported way to create and use single-use bot tokens is to create them dynamically, either by:

1. Using tctl bots add and following the instructions to use the randomly-generated token:

$ tctl bots add my-bot --roles <bot role>

2. Using a YAML payload to create the bot and its join token:

bot.yaml:

kind: bot
version: v1
metadata:
  name: my-bot
spec:
  roles: ['access']

token.yaml:

kind: token
version: v2
metadata:
  name: mybottoken
spec:
  roles: [Bot]
  join_method: token
  bot_name: my-bot

Then add them both to the cluster:

ubuntu@ip-172-31-30-140:~$ sudo tctl create -f token.yaml
provision_token "mybottoken" has been created

ubuntu@ip-172-31-30-140:~$ sudo tctl create -f bot.yaml
bot "my-bot" has been created

After this, you can start the bot and have it join the cluster correctly:

ubuntu@ip-172-31-30-140:~$ tbot start --data-dir=./tbot-test-data --destination-dir=./tbot-test --token=mybottoken --proxy-server=teleport.example.com:443 --join-method=token
2024-08-07T13:17:17Z INFO [TBOT]      Created directory path:./tbot-test-data config/destination_directory.go:130
2024-08-07T13:17:17Z INFO [TBOT:IDEN] Initializing bot identity. tbot/service_bot_identity.go:146
2024-08-07T13:17:17Z INFO [TBOT:IDEN] Loading existing bot identity from store. store:directory: ./tbot-test-data tbot/service_bot_identity.go:100
2024-08-07T13:17:17Z INFO [TBOT:IDEN] No existing bot identity found in store. Bot will join using configured token. tbot/service_bot_identity.go:105
2024-08-07T13:17:17Z INFO [TBOT:IDEN] Fetching bot identity using token tbot/service_bot_identity.go:348
2024-08-07T13:17:17Z INFO [TBOT]      Anonymous telemetry is not enabled. Find out more about Machine ID's anonymous telemetry at https://goteleport.com/docs/machine-id/reference/telemetry/ tbot/anonymous_telemetry.go:84
INFO             Attempting registration via proxy server. join/join.go:253
INFO             Successfully registered via proxy server. join/join.go:260
2024-08-07T13:17:17Z INFO [TBOT:IDEN] Fetched new bot identity identity:valid: after=2024-08-07T13:16:17Z, before=2024-08-07T14:17:17Z, duration=1h1m0s | kind=tls, renewable=true, disallow-reissue=false, roles=[bot-my-bot], principals=[-teleport-internal-join], generation=1 tbot/service_bot_identity.go:192
2024-08-07T13:17:17Z INFO [TBOT:IDEN] Identity initialized successfully tbot/service_bot_identity.go:208
2024-08-07T13:17:17Z INFO [TBOT]      Initialization complete. Starting services tbot/tbot.go:418
2024-08-07T13:17:17Z INFO [TBOT]      Starting service service:identity-output (directory: ./tbot-test) tbot/tbot.go:445
2024-08-07T13:17:17Z INFO [TBOT:SVC:] Attempting task task:output-renewal attempt:1 retry_limit:5 tbot/loop.go:92
2024-08-07T13:17:17Z INFO [TBOT:SVC:] Generating output tbot/service_identity_output.go:102
2024-08-07T13:17:17Z INFO [TBOT]      Starting service service:identity tbot/tbot.go:445
2024-08-07T13:17:17Z INFO [TBOT:IDEN] Beginning bot identity renewal loop ttl:1h0m0s interval:20m0s tbot/service_bot_identity.go:230
2024-08-07T13:17:17Z INFO [TBOT]      Starting service service:ca-rotation tbot/tbot.go:445
2024-08-07T13:17:17Z INFO [TBOT:CA-R] Started watching for CA rotations tbot/service_ca_rotation.go:213
2024-08-07T13:17:18Z INFO [TBOT:SVC:] Task succeeded. Waiting interval task:output-renewal interval:20m0s tbot/loop.go:139

[giriparus]

Thank you for taking this effort @webvictim, I had followed the same and I am able to get this work as a one time join for ephemeral tokens. Unfortunately, our use case is CI/CD via bitbucket pipelines which means I cannot create dynamic tokens like this on the fly. ( please correct me if I am wrong )

Let me explain the exact flow to you and maybe you can help me with the direction I should go with.
We run a bitbucket pipeline which does SSH into our server and runs a deploy script. I want to protect that server with teleport and hence this pipeline needs to be able to join the cluster as a user ( or here per se a "bot" ). And given this, I sort of need the token to be valid everytime the pipeline is run. I know this same thing can be achieved using github actions since there is an integration for it. But for bitbucket I thought I would be able to get this to work with static tokens ( even though yes they are less secure and I would prefer not to ).

I hope this helps you understand what I'm trying to achieve and let me know if I am going wrong somewhere or if there is another approach.