이메일을 통한 Access Request
이 가이드는 Teleport가 이메일을 통해 사용자에게 Just-in-Time Access Request 알림을 보내도록 설정하는 방법을 설명합니다. In Teleport Enterprise Cloud, Teleport manages the Email integration for you, and you can enroll the Email integration from the Teleport Web UI.
이 가이드는 Teleport가 이메일을 통해 사용자에게 Just-in-Time Access Request 알림을 보내도록 설정하는 방법을 설명합니다. 모든 조직은 최소한 일부 커뮤니케이션에 이메일을 사용하기 때문에, Teleport의 이메일 플러그인은 Access Request를 기존 워크플로에 통합하기 쉽게 만들어 생산성을 저해하지 않으면서 보안 모범 사례를 구현할 수 있게 합니다.

이 통합은 Teleport Enterprise (Cloud)에서 호스팅됩니다
In Teleport Enterprise Cloud, Teleport manages the Email integration for you, and you can enroll the Email integration from the Teleport Web UI.
Visit the Teleport Web UI and on the left sidebar, click Add New followed by Integration:

On the "Select Integration Type" menu, click the tile for your integration. You will see a page with instructions to set up the integration, as well as a form that you can use to configure the integration.

다음 설정 값을 제공하여 이메일 통합을 구성하고 연결합니다:
Sender: 발신자 주소를 설정합니다.
Fallback Recipient: Access Request 알림의 기본 수신자를 설정합니다.
Email Service: 원하는 이메일 서비스를 선택합니다. 참고: Teleport Enterprise (Cloud)에서는 Mailgun만 지원됩니다.

다음 Mailgun API 설정 값을 제공하여 Mailgun 통합을 완료합니다:
Domain: Mailgun 발송 도메인을 설정합니다.
Mailgun Private Key: Mailgun API 키를 설정합니다.
작동 방식#
Teleport 이메일 플러그인은 서드파티 SMTP 서비스와 Teleport Auth Service에 인증하고, Teleport Auth Service에서 Access Request 관련 감사 이벤트를 수신합니다. 사용자가 Access Request를 생성하면, 플러그인은 요청 검토자에게 이메일을 발송하며, 각 검토자가 Teleport Web UI에서 요청을 검토할 수 있는 링크를 포함합니다. Access Request의 대상 역할에 따라 플러그인이 알림을 보낼 검토자를 설정할 수 있습니다.
사전 요구사항#
-
A running Teleport Enterprise cluster. If you want to get started with Teleport, sign up for a free trial or set up a demo environment.
-
The
tctlandtshclients.Installing `tctl` and `tsh` clients
-
Determine the version of your Teleport cluster. The
tctlandtshclients must be at most one major version behind your Teleport cluster version. Send a GET request to the Proxy Service at/v1/webapi/findand use a JSON query tool to obtain your cluster version. Replace with the web address of your Teleport Proxy Service:$ TELEPORT_DOMAIN= $ TELEPORT_VERSION="$(curl -s https://$TELEPORT_DOMAIN/v1/webapi/find | jq -r '.server_version')" -
Follow the instructions for your platform to install
tctlandtshclients:
-
Recommended: Configure Machine & Workload Identity to provide short-lived
Teleport credentials to the plugin. Before following this guide, follow a
Machine & Workload Identity deployment guide
to run the tbot binary on your infrastructure.
- SMTP 서비스 접근 권한. Teleport 이메일 플러그인은 Mailgun 또는 사용자 이름과 비밀번호로 인증하는 일반 SMTP 서비스를 지원합니다.
- 이메일 플러그인을 실행할 Linux 호스트 또는 Kubernetes 클러스터.
Teleport 플러그인은 SMTP 서비스에 인증하기 위해 사용자 이름과 비밀번호를 사용해야 합니다. 이 자격 증명이 유출될 위험을 줄이려면, Teleport 플러그인 전용 이메일 계정을 설정하고 비밀번호를 정기적으로 교체해야 합니다.
To check that you can connect to your Teleport cluster, sign in with tsh login, then
verify that you can run tctl commands using your current credentials.
For example, run the following command, assigning to the domain name of the Teleport Proxy Service in your cluster and to your Teleport username:
$ tsh login --proxy= --user=
$ tctl status
# Cluster (=teleport.url=)
# Version (=teleport.version=)
# CA pin (=presets.ca_pin=)
If you can connect to the cluster and run the tctl status command, you can use your
current credentials to run subsequent tctl commands from your workstation.
If you host your own Teleport cluster, you can also run tctl commands on the computer that
hosts the Teleport Auth Service for full permissions.
1/7단계. RBAC 리소스 정의#
이메일 플러그인을 설정하기 전에, Teleport 클러스터에서 Role Access Request를 활성화해야 합니다.
For the purpose of this guide, we will define an editor-requester role, which
can request the built-in editor role, and an editor-reviewer role that can
review requests for the editor role.
Create a file called editor-request-rbac.yaml with the following content:
kind: role
version: v7
metadata:
name: editor-reviewer
spec:
allow:
review_requests:
roles: ['editor']
---
kind: role
version: v7
metadata:
name: editor-requester
spec:
allow:
request:
roles: ['editor']
thresholds:
- approve: 1
deny: 1
Create the roles you defined:
$ tctl create -f editor-request-rbac.yaml
role 'editor-reviewer' has been created
role 'editor-requester' has been created
(!docs/pages/includes/create-role-using-web.mdx!)
Allow yourself to review requests by users with the editor-requester role by
assigning yourself the editor-reviewer role.
(!docs/pages/includes/add-role-to-user.mdx role="editor-reviewer"!)
Create a user called myuser who has the editor-requester role. This user
cannot edit your cluster configuration unless they request the editor role:
$ tctl users add myuser --roles=editor-requester
tctl will print an invitation URL to your terminal. Visit the URL and log in
as myuser for the first time, registering credentials as configured for your
Teleport cluster.
Later in this guide, you will have myuser request the editor role so you can
review the request using the Teleport plugin.
2/7단계. Teleport 이메일 플러그인 사용자 정의#
플러그인에 필요한 권한은 사전 설정된 access-plugin 역할에 구성되어 있습니다. 플러그인에 대한 자격 증명을 생성하려면, Machine ID 봇 사용자 또는 일반 Teleport 사용자를 정의합니다.
If you haven't set up a Machine ID bot yet, refer to the
deployment guide
to run the tbot binary on your infrastructure.
Next, allow the Machine ID bot to generate credentials for the access-plugin
role. You can do this using tctl, replacing my-bot with the name of your bot:
$ tctl bots update my-bot --add-roles access-plugin
As with all Teleport users, the Teleport Auth Service authenticates the
access-plugin user by issuing short-lived TLS credentials. In this case, we
will need to request the credentials manually by impersonating the
access-plugin role and user.
If you are running a self-hosted Teleport Enterprise deployment and are using
tctl from the Auth Service host, you will already have impersonation
privileges.
To grant your user impersonation privileges for access-plugin, define a user
named access-plugin and a role named access-plugin-impersonator by adding
the following YAML document into a file called access-plugin-impersonator.yaml:
kind: user
metadata:
name: access-plugin
spec:
roles: ['access-plugin']
version: v2
---
kind: role
version: v7
metadata:
name: access-plugin-impersonator
spec:
allow:
impersonate:
roles:
- access-plugin
users:
- access-plugin
Create the user and role:
$ tctl create -f access-plugin-impersonator.yaml
user "access-plugin" has been created
role "access-plugin-impersonator" has been created
(!docs/pages/includes/create-role-using-web.mdx!)
Assign this role to the user you plan to use to generate credentials for the
access-plugin role and user:
(!docs/pages/includes/add-role-to-user.mdx role="access-plugin-impersonator"!)
You will now be able to generate signed certificates for the access-plugin
role and user.
3/7단계. 액세스 플러그인 ID 내보내기#
플러그인에 Teleport ID 파일 접근 권한을 부여합니다. 유출 시 위험도가 낮은 단기 ID 파일을 생성하기 위해 Machine ID를 사용하는 것을 권장하지만, 데모 배포에서는 tctl로 장기 ID 파일을 생성할 수 있습니다:
Configure tbot with an output that will produce the credentials needed by
the plugin. As the plugin will be accessing the Teleport API, the correct
output type to use is identity.
For this guide, the directory destination will be used. This will write these
credentials to a specified directory on disk. Ensure that this directory can
be written to by the Linux user that tbot runs as, and that it can be read by
the Linux user that the plugin will run as.
Modify your tbot configuration to add an identity output.
If running tbot on a Linux server, use the directory output to write
identity files to the /opt/machine-id directory:
services:
- type: identity
destination:
type: directory
# For this guide, /opt/machine-id is used as the destination directory.
# You may wish to customize this. Multiple outputs cannot share the same
# destination.
path: /opt/machine-id
If running tbot on Kubernetes, write the identity file to Kubernetes secret
instead:
services:
- type: identity
destination:
type: kubernetes_secret
name: teleport-plugin-email-identity
If operating tbot as a background service, restart it. If running tbot in
one-shot mode, execute it now.
You should now see an identity file under /opt/machine-id or a Kubernetes
secret named teleport-plugin-email-identity. This contains the private key and signed
certificates needed by the plugin to authenticate with the Teleport Auth
Service.
Like all Teleport users, access-plugin needs signed credentials in order to
connect to your Teleport cluster. You will use the tctl auth sign command to
request these credentials.
The following tctl auth sign command impersonates the access-plugin user,
generates signed credentials, and writes an identity file to the local
directory:
$ tctl auth sign --user=access-plugin --out=identity
The plugin connects to the Teleport Auth Service's gRPC endpoint over TLS.
The identity file, identity, includes both TLS and SSH credentials. The
plugin uses the SSH credentials to connect to the Proxy Service, which
establishes a reverse tunnel connection to the Auth Service. The plugin
uses this reverse tunnel, along with your TLS credentials, to connect to the
Auth Service's gRPC endpoint.
Certificate Lifetime
By default, tctl auth sign produces certificates with a relatively short
lifetime. For production deployments, we suggest using Machine
& Workload Identity to programmatically issue and renew
certificates for your plugin. See our Machine & Workload Identity getting started
guide to learn more.
Note that you cannot issue certificates that are valid longer than your existing credentials.
For example, to issue certificates with a 1000-hour TTL, you must be logged in with a session that is
valid for at least 1000 hours. This means your user must have a role allowing
a max_session_ttl of at least 1000 hours (60000 minutes), and you must specify a --ttl
when logging in:
$ tsh login --proxy=teleport.example.com --ttl=60060
If you are running the plugin on a Linux server, create a data directory to hold certificate files for the plugin:
$ sudo mkdir -p /var/lib/teleport/plugins/api-credentials
$ sudo mv identity /var/lib/teleport/plugins/api-credentials
If you are running the plugin on Kubernetes, Create a Kubernetes secret that contains the Teleport identity file:
$ kubectl -n teleport create secret generic --from-file=identity teleport-plugin-email-identity
Once the Teleport credentials expire, you will need to renew them by running the
tctl auth sign command again.
4/7단계. Teleport 이메일 플러그인 설치#
이 단계에서는 SMTP 서버에 네트워크 접근이 가능한 호스트에 Teleport 이메일 플러그인을 설치합니다. 이 호스트는 Teleport 클러스터와 이메일 발송에 사용되는 SMTP 서버 모두에 접근할 수 있는 시스템이면 됩니다.
로컬 SMTP 서버를 사용 중인가요?
로컬 SMTP 서버로 플러그인을 테스트하는 경우, 플러그인이 SMTP 서버에 연결하고 이메일 발송에 필요한 DNS 조회를 수행할 수 있도록 로컬 머신에 플러그인을 설치해야 합니다.
Teleport 클러스터는 플러그인을 위한 DNS 조회를 수행할 필요가 없습니다. 플러그인이 Teleport Proxy Service 또는 Teleport Auth Service로 다이얼아웃하기 때문입니다.
5/7단계. 플러그인 설정#
이제 이메일 플러그인이 Teleport에 연결하는 데 사용할 자격 증명을 생성했습니다. 이 자격 증명을 사용하여 Teleport에서 Access Request 알림을 수신하고 선택한 수신자에게 이메일로 전달하도록 플러그인을 설정합니다.
설정 파일 생성#
Teleport 이메일 플러그인은 TOML 형식의 설정 파일을 사용합니다. 다음 명령을 실행하여 기본 설정을 생성합니다:
$ teleport-email configure | sudo tee /etc/teleport-email.toml
이메일 플러그인 Helm Chart는 플러그인을 설정하기 위해 YAML 값 파일을 사용합니다.
로컬 워크스테이션에서 다음 예시를 기반으로 teleport-email-helm.yaml 파일을 생성합니다:
<div class="admonition note"><div class="admonition-title">Note</div><p>이 섹션의 내용은 원문 문서를 참조하세요. (<code>teleport-email-helm.yaml</code>)</p></div>
설정 파일 편집#
환경에 맞게 설정 파일을 편집합니다. 각 값을 설정하는 방법은 아래에서 설명합니다.
[teleport]#
If you are providing credentials to the plugin using a tbot binary that runs
on a Linux server, make sure the value of identity is the same as the path of
the identity file you configured tbot to generate, /opt/machine-id/identity.
Configure the plugin to periodically reload the identity file, ensuring that it does not attempt to connect to the Teleport Auth Service with expired credentials.
Add the following to the teleport section of the configuration:
refresh_identity = true
[mailgun] 또는 [smtp]#
Mailgun 또는 SMTP 서비스를 사용하는지에 따라 SMTP 서비스의 자격 증명을 제공합니다.
Linux 호스트에 이메일 플러그인을 배포하는 경우:
mailgun섹션에서domain을 Mailgun 계정의 도메인 이름과 서브도메인으로 지정합니다.mailgun.private_key를 Mailgun 프라이빗 키로 지정합니다.
Kubernetes에 이메일 플러그인을 배포하는 경우:
- Mailgun 프라이빗 키를 로컬 파일
mailgun-private-key에 씁니다. - 파일에서 Kubernetes 시크릿을 생성합니다:
$ kubectl -n teleport create secret generic mailgun-private-key --from-file=mailgun-private-key
mailgun.privateKeyFromSecret을mailgun-private-key로 지정합니다.
URL 스킴과 포트를 제외한 SMTP 서비스의 완전한 도메인 이름으로 host를 지정합니다. (테스트용 로컬 SMTP 서버를 사용하는 경우, host에 "localhost"를 사용합니다.) SMTP 서비스의 포트로 port를 지정합니다.
Linux 호스트에서 이메일 플러그인을 실행하는 경우, username과 password를 입력합니다.
비밀번호를 별도의 파일에 저장하고 password_file을 파일의 경로로 지정할 수도 있습니다. 플러그인은 파일을 읽고 파일의 내용을 비밀번호로 사용합니다.
Kubernetes에 이메일 플러그인을 배포하는 경우:
- SMTP 서비스의 비밀번호를 로컬 파일
smtp-password.txt에 씁니다. - 파일에서 Kubernetes 시크릿을 생성합니다:
$ kubectl -n teleport create secret generic smtp-password --from-file=smtp-password
smtp.passwordFromSecret을smtp-password로 지정합니다.
테스트를 위한 TLS 비활성화
신뢰할 수 있는 내부 SMTP 서버(예: 개발 머신의 로컬 SMTP 서버)에서 이메일 플러그인을 테스트할 때 TLS를 사용하지 않으려면, starttls_policy 설정을 disabled(항상 TLS 비활성화) 또는 opportunistic(서버가 STARTTLS 확장을 알리지 않는 경우 TLS 비활성화)으로 지정할 수 있습니다. 기본값은 항상 TLS를 강제하며, 무엇을 하는지 알고 위험을 이해하지 않는 한 이 설정을 지정하지 않아야 합니다.
Kubernetes 배포의 경우, starttls_policy는 이메일 플러그인의 Helm 값 파일에서 smtp.starttlsPolicy로 불립니다.
[delivery]#
Teleport 플러그인이 메시지를 보낼 이메일 주소로 sender를 지정합니다.
[role_to_recipients]#
role_to_recipients 맵(Helm 사용자의 경우 roleToRecipients)은 사용자가 특정 역할에 대한 액세스를 요청할 때 이메일 플러그인이 알릴 수신자를 설정합니다. 플러그인이 Auth Service에서 Access Request를 수신하면, 요청된 역할을 조회하고 알릴 수신자를 식별합니다.
다음은 role_to_recipients 맵의 예시입니다. 각 값은 단일 문자열 또는 문자열 배열이 될 수 있습니다:
[role_to_recipients]
"*" = ["security@example.com", "executive-team@example.com"]
"dev" = "eng@example.com"
"dba" = "mallory@example.com"
Helm 차트에서 role_to_recipients 필드는 roleToRecipients로 불리며, 키는 문자열이고 값은 문자열 배열인 다음 형식을 사용합니다:
roleToRecipients:
"*": ["security@example.com", "executive-team@example.com"]
"dev": ["eng@example.com"]
"dba": ["mallory@example.com"]
role_to_recipients 맵에서 각 키는 Teleport 역할의 이름입니다. 각 값은 해당 역할에 대한 Access Request를 수신할 때 플러그인이 이메일을 보낼 수신자를 설정합니다. 각 문자열은 이메일 주소여야 합니다.
role_to_recipients 맵에는 "*" 항목도 포함해야 합니다. 이 항목은 다른 항목이 특정 역할 이름과 일치하지 않을 때 플러그인이 조회합니다. 위 예시에서 dev와 dba 이외의 역할에 대한 요청은 security@example.com과 executive-team@example.com에 알림을 보냅니다.
제안된 검토자
사용자는 Access Request를 생성할 때 검토자를 제안할 수 있습니다. 예를 들어:
$ tsh request create --roles=dbadmin --reviewers=alice@example.com,ivan@example.com
Access Request에 제안된 검토자가 포함된 경우, 이메일 플러그인은 이들을 알릴 수신자 목록에 추가합니다. 제안된 검토자가 이메일 주소인 경우, 플러그인은 role_to_recipients에 설정된 수신자 외에도 해당 수신자에게 메시지를 보냅니다.
YOUR_EMAIL_ADDRESS를 적절한 주소로 바꿔 role_to_recipients 설정에 다음을 추가하여 사용자가 editor 역할을 요청할 때 알림을 받도록 이메일 플러그인을 설정합니다:
[role_to_recipients]
"*" = "YOUR_EMAIL_ADDRESS"
"editor" = "YOUR_EMAIL_ADDRESS"
roleToRecipients:
"*": "YOUR_EMAIL_ADDRESS"
"editor": "YOUR_EMAIL_ADDRESS"
역할 매핑 없이 수신자 설정
역할-수신자 매핑을 사용하지 않을 계획이라면, delivery.recipients 필드를 사용하여 모든 Access Request 이벤트에 대해 정적 수신자 목록에 알림을 보내도록 Teleport 이메일 플러그인을 설정할 수 있습니다:
[delivery]
recipients = ["eng@exmaple.com", "dev@example.com"]
delivery:
recipients: ["eng@exmaple.com", "dev@example.com"]
delivery.recipients를 사용하는 경우, role_to_recipients 설정 섹션을 제거해야 합니다. 내부적으로 delivery.recipients는 와일드카드 값 "*" 아래의 role_to_recipients 매핑에 수신자 목록을 지정합니다.
설정은 다음과 유사해야 합니다:
# /etc/teleport-email.toml
[teleport]
addr = "example.com:443"
identity = "/var/lib/teleport/plugins/email/identity"
refresh_identity = true
[mailgun]
domain = "sandbox123abc.mailgun.org"
private_key = "xoxb-fakekey62b0eac53565a38c8cc0316f6"
# As an alternative, you can use SMTP server credentials:
#
# [smtp]
# host = "smtp.gmail.com"
# port = 587
# username = "username@gmail.com"
# password = ""
# password_file = "/var/lib/teleport/plugins/email/smtp_password"
# starttls_policy = "mandatory"
[delivery]
sender = "noreply@example.com"
[role_to_recipients]
"*" = "eng@example.com"
"editor" = ["admin@example.com", "execs@example.com"]
[log]
output = "stderr" # Logger output. Could be "stdout", "stderr" or "/var/lib/teleport/email.log"
severity = "INFO" # Logger severity. Could be "INFO", "ERROR", "DEBUG" or "WARN".
# teleport-email-helm.yaml
teleport:
address: "teleport.example.com:443"
identitySecretName: teleport-plugin-email-identity
identitySecretPath: identity
mailgun:
domain: "sandbox123abc.mailgun.org"
privateKeyFromSecret: "mailgun-private-key"
# As an alternative, you can use SMTP server credentials:
#
# smtp:
# host: "smtp.gmail.com"
# port: 587
# username: "username@gmail.com"
# passwordFromSecret: "smtp-password"
# starttls_policy = "mandatory"
delivery:
sender: "noreply@example.com"
roleToRecipients:
"*": "eng@example.com"
"editor": ["admin@example.com", "execs@example.com"]
6/7단계. 이메일 플러그인 테스트#
설정을 완료한 후, 이제 플러그인을 실행하고 이메일 기반 Access Request 흐름을 테스트할 수 있습니다:
$ teleport-email start
모든 것이 예상대로 작동하면, 로그 출력은 다음과 같아야 합니다:
$ teleport-email start
INFO Starting Teleport Access Email Plugin (): email/app.go:80
INFO Plugin is ready email/app.go:101
플러그인 시작:
$ docker run -v <path-to-config>:/etc/teleport-email.toml public.ecr.aws/gravitational/teleport-plugin-email:(=teleport.version=) start
플러그인 설치:
$ helm upgrade --install teleport-plugin-email teleport/teleport-plugin-email --values teleport-email-helm.yaml
플러그인의 로그를 검사하려면, 다음 명령을 사용합니다:
$ kubectl logs deploy/teleport-plugin-email
teleport-email-helm.yaml에서 log.severity를 DEBUG로 설정하고 위의 helm upgrade ... 명령을 다시 실행하여 디버그 로그를 활성화할 수 있습니다. 그런 다음 다음 명령으로 플러그인을 재시작할 수 있습니다:
$ kubectl rollout restart deployment teleport-plugin-email
Access Request 생성#
이전에 설정한 수신자들은 이메일로 요청 알림을 받아야 합니다.
요청 해결#
Once you receive an Access Request message, click the link to visit Teleport and approve or deny the request:

Reviewing from the command line
You can also review an Access Request from the command line:
7/7단계. systemd 설정#
이 섹션은 Linux 호스트에서 Teleport 이메일 플러그인을 실행하는 경우에만 해당됩니다.
프로덕션 환경에서는 systemd와 같은 init 시스템을 통해 Teleport 플러그인 데몬을 시작하는 것을 권장합니다. systemd를 위한 권장 Teleport 플러그인 서비스 유닛 파일은 다음과 같습니다:
<div class="admonition note"><div class="admonition-title">Note</div><p>이 섹션의 내용은 원문 문서를 참조하세요. (<code>teleport-email.service</code>)</p></div>
이를 /usr/lib/systemd/system/ 또는 systemd가 지원하는 다른 유닛 파일 로드 경로에 teleport-email.service로 저장합니다.
플러그인을 활성화하고 시작합니다:
$ sudo systemctl enable teleport-email
$ sudo systemctl start teleport-email
문제 해결#
이 섹션의 내용은 원문 문서를 참조하세요. (access-plugin-troubleshooting.mdx)
