![Fork me on GitHub](/docs/_next/image/?url=%2Fdocs%2F_next%2Fstatic%2Fmedia%2Fforkme.b9234619.webp&w=256&q=75)
Teleport
Machine ID FAQ
- Version 17.x
- Version 16.x
- Version 15.x
- Version 14.x
- Older Versions
Can Machine ID be used within CI/CD jobs?
On CI/CD platforms where your workflow runs in an ephemeral environment (e.g no persistent state exists between individual workflow runs), Machine ID works best where a supported join method exists. These are:
- GitHub Actions
- CircleCI
- GitLab
- AWS
- GCP
- Azure
- Kubernetes
- Spacelift
On CI/CD platforms where you control the runner environment (e.g self-hosted Jenkins runner), Machine ID can run as a daemon on the runner and the generated credentials can be mounted into the environment of your individual workflow runs.
Can Machine ID be used with Trusted Clusters ?
From Teleport 12.2, you can use Machine ID for SSH Access in trusted leaf clusters.
We currently do not support access to applications, databases, or Kubernetes clusters in leaf clusters.
Should I define allowed logins as user traits or within roles?
When defining the logins that your bot will be allowed to use, there are two options:
- Directly adding the login to the
logins
section of the role that your bot will impersonate. - Adding the login to the logins trait of the bot user, and impersonating a role
that includes the
{{ internal.logins }}
role variable. This is usually done by providing the--logins
parameter when creating the bot.
For simpler scenarios — where you only expect the bot to use a single output
or role — you can add the login to the logins trait of the bot user. This
approach allows you to leverage default roles like access
.
For situations where your bot is producing certificates for different roles in different outputs, it is important to consider whether using a login trait grants access to resources that you didn't intend. To prevent a login trait from granting access you didn't intend, we recommend that you create bespoke roles that explicitly specify the logins that should be included in the certificates.
Can Machine ID be used with per-session MFA?
We do not currently support Machine ID and per-session MFA. Enabling per-session MFA globally, or for roles impersonated by Machine ID, will prevent credentials produced by Machine ID from being used to connect to resources.
As a work-around, ensure that per-session MFA is enforced on individual roles rather than enforced globally, and that it is not enforced for roles that you will impersonate using Machine ID.
Can Machine ID be used with Device Trust?
We do not currently support Machine ID and Device Trust. Requiring Device Trust cluster-wide or for roles impersonated by Machine ID will prevent credentials produced by Machine ID from being used to connect to resources.
As a work-around, configure Device Trust enforcement on a role-by-role basis and ensure that it is not required for roles that you will impersonate using Machine ID.
Can Machine ID be used to generate long-lived certificates?
Machine ID cannot currently be used to generate certificates valid for longer
than 24 hours, and requests for longer certificates using the certificate_ttl
parameter will be reduced to this 24 hour limit.
This limit serves multiple purposes. For one, it encourages security best practices by only ever issuing very short lived certificates. Additionally, as Machine ID allows for certificate renewal, this limit helps to prevent further exploitation should a Machine ID identity be compromised: an attacker could use a stolen renewable certificate to request very long lived certificates and maintain access for a much longer period.
If your use case absolutely requires long-lived certificates,
tctl auth sign
can
alternatively be used, however this loses the security benefits of Machine ID's
short-lived renewable certificates.