diff --git a/docs/img/enterprise/plugins/pagerduty/new-access-req-incident.png b/docs/img/enterprise/plugins/pagerduty/new-access-req-incident.png
new file mode 100644
index 0000000000000..0ef6a8ed2dcd5
Binary files /dev/null and b/docs/img/enterprise/plugins/pagerduty/new-access-req-incident.png differ
diff --git a/docs/img/enterprise/plugins/pagerduty/pagerduty-api-integration.png b/docs/img/enterprise/plugins/pagerduty/pagerduty-api-integration.png
new file mode 100644
index 0000000000000..763d7184b2605
Binary files /dev/null and b/docs/img/enterprise/plugins/pagerduty/pagerduty-api-integration.png differ
diff --git a/docs/img/enterprise/plugins/pagerduty/pagerduty-integrations.png b/docs/img/enterprise/plugins/pagerduty/pagerduty-integrations.png
new file mode 100644
index 0000000000000..f3478c5a044e0
Binary files /dev/null and b/docs/img/enterprise/plugins/pagerduty/pagerduty-integrations.png differ
diff --git a/docs/pages/access-controls/access-request-plugins/ssh-approval-pagerduty.mdx b/docs/pages/access-controls/access-request-plugins/ssh-approval-pagerduty.mdx
index dc3170abdd796..fcc618bae6c32 100644
--- a/docs/pages/access-controls/access-request-plugins/ssh-approval-pagerduty.mdx
+++ b/docs/pages/access-controls/access-request-plugins/ssh-approval-pagerduty.mdx
@@ -1,56 +1,393 @@
---
-title: SSH login approval via Pager Duty
-description: How to configure SSH login approval using PagerDuty and Teleport
-h1: SSH Login Approval using PagerDuty
-videoBanner: RzTB4Lsm09M
+title: Access Requests with PagerDuty
+description: How to set up Teleport's PagerDuty plugin for privilege elevation approvals.
---
-This guide will talk through how to setup Teleport with PagerDuty. Teleport's
-PagerDuty integration allows you to treat Teleport access and permission
-requests as PagerDuty incidents, notify the appropriate team, and approve
-or deny the requests via PagerDuty special action.
+With Teleport's PagerDuty integration, engineers can access the infrastructure
+they need to resolve incidents quickly—without longstanding admin permissions
+that can become a vector for attacks.
-## Setup
+Teleport's PagerDuty integration allows you to treat Teleport Role Access
+Requests as PagerDuty incidents, notify the appropriate on-call team, and
+approve or deny the requests via PagerDuty. You can also configure the plugin to
+approve Role Access Requests automatically if the user making the request is on
+the on-call team for a service affected by an incident.
-### Prerequisites
+This guide will explain how to set up Teleport's Access Request plugin for
+PagerDuty.
-This guide assumes that you have:
+
-Teleport Cloud requires that plugins connect through the Proxy Service (`mytenant.teleport.sh:443`). Open Source and Enterprise installations can connect to the Auth Service (`auth.example.com:3025`) directly.
+## Prerequisites
+
+(!/docs/pages/includes/commercial-prereqs-tabs.mdx!)
+
+- A PagerDuty account with the "Admin", "Global Admin", or "Account Owner"
+ roles. These roles are necessary for generating an API token that can list and
+ look up user profiles.
+
+ You can see your role by visiting your user page in PagerDuty, navigating to
+ the "Permissions & Teams" tab, and checking the value of the "Base Role"
+ field.
+
+- A host where you will run the PagerDuty plugin.
+
+
+
+We recommend installing Teleport plugins on the same host as the Teleport Proxy
+Service. This is an ideal location as plugins have a low memory footprint, and
+will require both public internet access and Teleport Auth Service access.
+
+
+
+
+
+Install the Teleport PagerDuty plugin on a host that can access both your
+Teleport Cloud tenant and PagerDuty.
+
+
(!docs/pages/includes/tctl.mdx!)
-### Create a user and role for access
+## Step 1/8. Create services
-(!docs/pages/includes/plugins/rbac.mdx!)
+To demonstrate the PagerDuty plugin, create two services in PagerDuty. For each
+service, fill in only the "Name" field and skip all other configuration screens,
+leaving options as the defaults:
-### Export the access-plugin certificate
+- `Teleport Access Request Notifications`
+- `My Critical Service`
-(!docs/pages/includes/plugins/identity-export.mdx!)
+We will configure the PagerDuty plugin to create an incident in the `Teleport
+Access Request Notifications` service when certain users create an Access
+Request.
-We'll reference these files later when [configuring the plugins](#config-file).
+For users on the on-call team for `My Critical Service` (in this case, your
+PagerDuty user), we will configure the PagerDuy plugin to approve Access
+Requests automatically, letting them investigate incidents on the service
+quickly.
+## Step 2/8. Define RBAC resources
-### Setting up a PagerDuty API key
+The Teleport PagerDuty plugin works by receiving Access Request events from the
+Teleport Auth Service and, based on these events, interacting with the PagerDuty
+API.
-In your PagerDuty dashboard, go to **Configuration → API Access → Create New API Key**, add a key description, and save the key. We'll use the key in the plugin config file later.
+In this section, we will show you how to configure the PagerDuty plugin by
+defining the following RBAC resources:
-**Create a PagerDuty API key**
-
+- A role called `editor-requester`, which can request the built-in `editor`
+ role. We will configure this role to open a PagerDuty incident whenever a
+ user requests it, notifying the on-call team for the `Teleport Access Request
+ Notifications` service.
+- A role called `demo-role-requester`, which can request a role called
+ `demo-role`. We will configure the PagerDuty plugin to auto-approve this
+ request whenever the user making it is on the on-call team for `My Critical
+ Service`.
+- A user and role called `access-plugin` that the PagerDuty plugin will assume
+ in order to authenticate to the Teleport Auth Service. This role will have
+ permissions to approve Access Requests from users on the on-call team for `My
+ Critical Service` automatically.
+- A role called `access-plugin-impersonator` that allows you to generate signed
+ credentials that the PagerDuty plugin can use to authenticate with your
+ Teleport cluster.
-**Create a service account**
-
+### `editor-requester`
-## Downloading and installing the plugin
+Create a file called `editor-request-rbac.yaml` with the following content,
+which defines a role called `editor-reviewer` that can review requests for the
+`editor` role, plus an `editor-requester` role that can request this role.
+
+```yaml
+kind: role
+version: v5
+metadata:
+ name: editor-reviewer
+spec:
+ allow:
+ review_requests:
+ roles: ['editor']
+---
+kind: role
+version: v5
+metadata:
+ name: editor-requester
+spec:
+ allow:
+ request:
+ roles: ['editor']
+ thresholds:
+ - approve: 1
+ deny: 1
+ annotations:
+ pagerduty_notify_service: ["Teleport Access Request Notifications"]
+```
+
+The Teleport Auth Service *annotates* Access Request events with metadata based
+on the roles of the Teleport user submitting the Access Request. The PagerDuty
+plugin reads these annotations to determine how to respond to a new Access
+Request event.
+
+Whenever a user with the `editor-requester` role requests the `editor` role, the
+PagerDuty plugin will read the `pagerduty_notify_service` annotation and notify
+PagerDuty to open an incident in the specified service, `Teleport Access Request
+Notifications`, until someone with the `editor-reviewer` role approves or denies
+the request.
+
+Create the roles you defined:
+
+```code
+$ tctl create -f editor-request-rbac.yaml
+role 'editor-reviewer' has been created
+role 'editor-requester' has been created
+```
+
+### `demo-role-requester`
+
+Create a file called `demo-role-requester.yaml` with the following content:
+
+```yaml
+kind: role
+version: v5
+metadata:
+ name: demo-role
+---
+kind: role
+version: v5
+metadata:
+ name: demo-role-requester
+spec:
+ allow:
+ request:
+ roles: ['demo-role']
+ thresholds:
+ - approve: 1
+ deny: 1
+ annotations:
+ pagerduty_services: ["My Critical Service"]
+```
+
+Users with the `demo-role-requester` role can request the `demo-role` role. When
+such a user makes this request, the PagerDuty plugin will read the
+`pagerduty_services` annotation. If the user making the request is on the
+on-call team for a service listed as a value for the annotation, the plugin will
+approve the Access Request automatically.
+
+In this case, the PagerDuty plugin will approve any requests from users on the
+on-call team for `My Critical Service`.
+
+Create the resources:
+
+```code
+$ tctl create -f demo-role-requester.yaml;
+```
+
+
+
+For auto-approval to work, the user creating an Access Request must have a
+Teleport username that is also the email address associated with a PagerDuty
+account. In this guide, we will add the `demo-role-requester` role to your own
+Teleport account—which we assume is also your email address for PagerDuty—so you
+can request the `demo-role` role.
+
+
+
+### `access-plugin`
+
+Teleport's Access Request plugins authenticate to your Teleport cluster as a
+user with permissions to list, read, and update Access Requests. This way,
+plugins can retrieve Access Requests from the Teleport Auth Service, present
+them to reviewers, and modify them after a review.
+
+Define a user and role called `access-plugin` by adding the following content to
+a file called `access-plugin.yaml`:
+
+```yaml
+kind: role
+version: v5
+metadata:
+ name: access-plugin
+spec:
+ allow:
+ rules:
+ - resources: ['access_request']
+ verbs: ['list', 'read', 'update']
+ - resources: ['access_plugin_data']
+ verbs: ['update']
+ review_requests:
+ roles: ['demo-role']
+ where: 'contains(request.system_annotations["pagerduty_services"], "My Critical Service")'
+---
+kind: user
+metadata:
+ name: access-plugin
+spec:
+ roles: ['access-plugin']
+version: v2
+```
+
+Notice that the `access-plugin` role includes an `allow.review_requests.roles`
+field with `demo-role` as a value. This allows the plugin to review requests for
+the `demo-role` role.
+
+We are also restricting the `access-plugin` role to reviewing only Access
+Requests associated with `My Critical Service`. To do so, we have defined a
+*predicate expression* in the `review_requests.where` field. This expression
+indicates that the plugin *cannot* review requests for `demo-role` unless the
+request contains an annotation with the key `pagerduty_services` and the value
+`My Critical Service`.
+
+
+
+The `where` field includes a predicate expression that determines whether a
+reviewer is allowed to review a specific request. You can include two functions
+in a predicate expression:
+
+|Function|Description|Example|
+|---|---|---|
+|`equals`|A field is equivalent to a value.|`equals(request.reason, "resolve an incident")`
+|`contains`|A list of strings includes a value.|`contains(reviewer.traits["team"], "devops")`|
+
+When you use the `where` field, you can include the following fields in your
+predicate expression:
+
+|Field|Type|Description|
+|---|---|---|
+|`reviewer.roles`|`[]string`|A list of the reviewer's Teleport role names|
+|`reviewer.traits`|`map[string][]string`|A map of the reviewer's Teleport traits by the name of the trait|
+|`request.roles`|`[]string`|A list of the Teleport roles a user is requesting|
+|`request.reason`|`string`|The reason attached to the request|
+|`request.system_annotations`| `map[string][]string`|A map of annotations for the request by annotation key, e.g., `pagerduty_services`|
+
+You can combine functions using the following operators:
+
+|Operator|Format|Description|
+|---|---|---|
+|`&&`|`function && function`|Evaluates to true if both functions evaluate to true|
+|`\|\|`|`function \|\| function`|Evalutes to true if either one or both functions evaluate to true|
+|`!`| `!function`|Evaluates to true if the function evaluates to false|
+
+An example of a function is `equals(request.reason, "resolve an incident")`. To
+configure an `allow` condition to match any Access Request that does not include
+the reason, "resolve an incident", you could use the function,
+`!equals(request.reason, "resolve an incident")`.
+
+
+
+Create the user and role:
+
+```code
+$ tctl create -f access-plugin.yaml
+```
+
+### `access-plugin-impersonator`
+
+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 using `tctl` from the Auth
+Service host, you will already have impersonation privileges.
+
+To grant your user impersonation privileges for `access-plugin`, define a role
+called `access-plugin-impersonator` by pasting the following YAML document into
+a file called `access-plugin-impersonator.yaml`:
+
+```yaml
+kind: role
+version: v5
+metadata:
+ name: access-plugin-impersonator
+spec:
+ allow:
+ impersonate:
+ roles:
+ - access-plugin
+ users:
+ - access-plugin
+```
+
+Create the `access-plugin-impersonator` role:
+
+```code
+$ tctl create -f access-plugin-impersonator.yaml
+```
+
+### Add roles to your user
+
+Later in this guide, your Teleport user will take three actions that require
+additional permissions:
+
+- Generate signed credentials that the PagerDuty plugin will use to connect to
+ your Teleport Cluster
+- Manually review an Access Request for the `editor` role
+- Create an Access Request for the `demo-role` role
+
+To grant these permissions to your user, give your user the `editor-reviewer`,
+`access-plugin-impersonator`, and `demo-role-requester` roles we defined
+earlier.
+
+Retrieve your user definition:
+
+```code
+$ TELEPORT_USER=$(tsh status --format=json | jq -r .active.username)
+$ tctl get users/${TELEPORT_USER?} > myuser.yaml
+```
-We recommend installing Teleport plugins alongside the Teleport Proxy. This is an ideal
-location as plugins have a low memory footprint, and will require both public internet access
-and Teleport Auth Service access.
+Edit `myuser.yaml` to include the roles you just created:
+
+```diff
+ roles:
+ - access
+ - auditor
+ - editor
++ - editor-reviewer
++ - access-plugin-impersonator
++ - demo-role-requester
+```
+
+Apply your changes:
+
+```code
+$ tctl create -f myuser.yaml
+```
+
+Log out of your Teleport cluster and log in again. You will now be able to
+review requests for the `editor` role, request the `demo-role` role, and
+generate signed certificates for the `access-plugin` role and user.
+
+### Create a user who will request access
+
+Create a user called `myuser` who has the `editor-requester` role. Later in this
+guide, you will create an Access Request as this user to test the PagerDuty
+plugin:
+
+```code
+$ 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.
+
+## Step 3/8. Install the Teleport PagerDuty plugin
+
+We currently only provide `linux-amd64` binaries. You can also compile these
+plugins from source. You can run the plugin from a remote host or your local
+development machine.
@@ -58,11 +395,15 @@ and Teleport Auth Service access.
$ curl -L -O https://get.gravitational.com/teleport-access-pagerduty-v(=teleport.plugin.version=)-linux-amd64-bin.tar.gz
$ tar -xzf teleport-access-pagerduty-v(=teleport.plugin.version=)-linux-amd64-bin.tar.gz
$ cd teleport-access-pagerduty
- $ ./install
+ $ sudo ./install
+ Teleport PagerDuty Plugin binaries have been copied to /usr/local/bin
+ You can run teleport-pagerduty configure > /etc/teleport-pagerduty.toml to
+ bootstrap your config file.
```
- To install from source you need `git` and `go` installed. If you do not have Go installed, visit the Go [downloads page](https://go.dev/dl/).
+ To install from source you need `git` and `go` installed. If you do not have
+ Go installed, visit the Go [downloads page](https://go.dev/dl/).
```code
# Checkout teleport-plugins
@@ -70,46 +411,157 @@ and Teleport Auth Service access.
$ cd teleport-plugins/access/pagerduty
$ make
```
-Run `./install` from `teleport-pagerduty` or place the executable in the appropriate `/usr/bin` or `/usr/local/bin` on the server installation.
+
+Run `./install` from `teleport-pagerduty`.
+
```code
- $ docker pull quay.io/gravitational/teleport-plugin-pagerduty:(=teleport.plugin.version=)
+ $ docker pull public.ecr.aws/gravitational/teleport-plugin-pagerduty:(=teleport.plugin.version=)
```
-### Config file
+## Step 4/8. Export the access plugin identity
+
+(!docs/pages/includes/plugins/identity-export.mdx!)
+
+## Step 5/8. Set up a PagerDuty API key
+
+Generate an API key that the PagerDuty plugin will use to create and modify
+incidents as well as list users, services, and on-call policies.
+
+In your PagerDuty dashboard, go to **Integrations → API Access Keys** and click
+**Create New API Key**. Add a key description, e.g., "Teleport integration".
+Leave "Read-only API Key" unchecked. Copy the key to a file on your local
+machine. We'll use the key in the plugin config file later.
-Teleport's PagerDuty plugin has its own configuration file in TOML format. Before starting the plugin for the first time, you'll need to generate and edit that config file.
+
+
+## Step 6/8. Configure the PagerDuty plugin
+
+At this point, you have generated credentials that the PagerDuty plugin will use
+to connect to Teleport and the PagerDuty API. You will now configure the
+PagerDuty plugin to use these credentials, plus adjust any settings required for
+your environment.
+
+Teleport's PagerDuty plugin has its own configuration file in TOML format. On
+the host where you will run the PagerDuty plugin, generate a boilerplate config
+by running the following commands:
```code
$ teleport-pagerduty configure > teleport-pagerduty.toml
$ sudo mv teleport-pagerduty.toml /etc
```
-#### Editing the config file
+
+
+The PagerDuty plugin expects the configuration to be in
+`/etc/teleport-pagerduty.toml`, but you can override this with the `--config`
+flag when you run the plugin binary later in this guide.
+
+
+
+Edit the configuration file in `/etc/teleport-pagerduty.toml` as explained
+below:
-After generating the config, edit it as follows:
+### `[teleport]`
+
+The PagerDuty plugin uses this section to connect to your Teleport cluster:
+
+
+
+The address and credentials you configure depend on whether your plugin can
+access the Auth Service directly:
-
-```yaml
-(!examples/resources/plugins/teleport-pagerduty-self.toml!)
+
+
+Set `addr` to your Proxy Service address with port `443`.
+
+Set `identity` to the identity file generated earlier:
+
+```toml
+[teleport]
+addr = "mytenant.teleport.sh:443"
+identity = "/var/lib/teleport/plugins/slack/auth.pem"
+```
+
+
+
+Set `addr` to the address and port of your Auth Service. This address must be
+reachable from the Teleport PagerDuty plugin.
+
+Set `client_key`, `client_crt`, and `root_cas` to the identity files
+generated earlier:
+
+```toml
+[teleport]
+addr = "localhost:3025"
+client_key = "/var/lib/teleport/plugins/slack/auth.key" # Teleport GRPC client secret key
+client_crt = "/var/lib/teleport/plugins/slack/auth.crt" # Teleport GRPC client certificate
+root_cas = "/var/lib/teleport/plugins/slack/auth.cas" # Teleport cluster CA certs
```
-
+
+
+
+
+
+Set `addr` to your Teleport Cloud tenant address with port `443`.
+
+Set `identity` to the identity file generated earlier:
+
+```toml
+[teleport]
+addr = "mytenant.teleport.sh:443"
+identity = "/var/lib/teleport/plugins/slack/auth.pem"
+```
+
+
+
+### `[pagerduty]`
+
+Assign `api_key` to the PagerDuty API key you generated earlier.
+
+Assign `user_email` to the email address of a PagerDuty user on the account
+associated with your API key. When the PagerDuty plugin creates a new incident,
+PagerDuty will display this incident as created by that user.
+
+
+
+This guide has assumed that the Teleport PagerDuty plugin uses
+`pagerduty_notify_service` annotation to determine which services to notify of
+new Access Request events and the `pagerduty_services` annotation to configure
+auto-approval.
+
+If you would like to use a different name for these annotations in your Teleport
+roles, you can assign the `pagerduty.notify_service` and `pagerduty.services`
+fields.
+
+
+
+The final configuration should resemble the following:
+
+
+
```yaml
(!examples/resources/plugins/teleport-pagerduty-cloud.toml!)
```
+
+```yaml
+(!examples/resources/plugins/teleport-pagerduty-self.toml!)
+```
+
-### Testing the plugin
+## Step 7/8. Test the PagerDuty plugin
-With the config above, you should be able to run the plugin invoking
-`teleport-pagerduty start -d`. The will provide some debug information to make sure
-the bot can connect to PagerDuty.
+After you configure the PagerDuty plugin, run the following command to start it.
+The `-d` flag will provide debug information to ensure that the plugin can
+connect to PagerDuty and your Teleport cluster:
```code
$ teleport-pagerduty start -d
@@ -124,58 +576,92 @@ $ teleport-pagerduty start -d
# DEBU Setting up the webhook extensions pagerduty/main.go:178
```
-By default, `teleport-pagerduty` will assume its config is in `/etc/teleport-pagerduty.toml`, but you can override it with `--config` option.
+### Create an Access Request
-### Set up systemd
+As the Teleport user `myuser`, create an Access Request for the `editor` role:
-In production, we recommend starting the Teleport plugin daemon via an init system like systemd. Here's the recommended Teleport plugin service unit file for systemd:
+(!docs/pages/includes/plugins/create-request.mdx!)
-```code
-(!examples/systemd/plugins/teleport-pagerduty.service!)
+You should see a log resembling the following on your PagerDuty plugin host:
+
+```
+INFO Successfully created PagerDuty incident pd_incident_id:00000000000000
+pd_service_name:Teleport Access Request Notifications
+request_id:00000000-0000-0000-0000-000000000000 request_op:put
+request_state:PENDING pagerduty/app.go:366
```
-Save this as `teleport-pagerduty.service`.
+In PagerDuty, you will see a new incident containing information about the
+Access Request:
-#### Example PagerDuty request
+
-
+(!docs/pages/includes/plugins/resolve-request.mdx!)
+
+
+
+When the PagerDuty plugin sends a notification, anyone who receives the
+notification can follow the enclosed link to an Access Reqeust URL. While users
+must be authorized via their Teleport roles to review Access Request, you
+should still check the Teleport audit log to ensure that the right users are
+reviewing the right requests.
+
+When auditing Access Request reviews, check for events with the type `Access
+Request Reviewed` in the Teleport Web UI and `access_request.review` if reviewing the audit log on the
+Auth Service host.
+
+
+
+### Trigger an auto-approval
-## On-call auto-approval
+As your Teleport user, create an Access Request for the `demo-role` role.
-The PagerDuty plugin has an option to auto-approve Access Requests. This
-feature will map an external SSO identity to a PagerDuty on-call email address.
-If the user requesting matches the person on call the request will be
-automatically approved.
+You will see a log similar to the following on your PagerDuty plugin host:
-This feature can be enabled via the PagerDuty config file using `auto_approve = true`.
+```
+INFO Successfully submitted a request approval
+pd_user_email:myuser@example.com pd_user_name:My User
+request_id:00000000-0000-0000-0000-000000000000 request_op:put
+request_state:PENDING pagerduty/app.go:511
+```
+
+Your Access Request will appear as `APPROVED`:
+```code
+$ tsh requests ls
+ID User Roles Created (UTC) Status
+------------------------------------ ------------------ --------- ------------------- --------
+00000000-0000-0000-0000-000000000000 myuser@example.com demo-role 12 Aug 22 18:30 UTC APPROVED
```
-# Example teleport-pagerduty.toml snippet
-#...
-[pagerduty]
-api_key = "key" # PagerDuty API Key
-user_email = "me@example.com" # PagerDuty bot user email (Could be admin email)
-service_id = "PIJ90N7" # PagerDuty service id
-auto_approve = true # Auto approve
+
+## Step 8/8. Set up systemd
+
+In production, we recommend starting the Teleport plugin daemon via an init
+system like systemd. Here's the recommended Teleport plugin service unit file
+for systemd:
+
+```ini
+(!examples/systemd/plugins/teleport-pagerduty.service!)
```
-## Audit log
+Save this as `teleport-pagerduty.service` in either `/usr/lib/systemd/system/`
+or another [unit file load
+path](https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Unit%20File%20Load%20Path)
+supported by systemd.
+
+Enable and start the plugin:
-The plugin will let anyone with access to the PagerDuty account so it's
-important to review Teleport's audit log.
+```code
+$ sudo systemctl enable teleport-pagerduty
+$ sudo systemctl start teleport-pagerduty
+```
## Feedback
-If you have any issues with this plugin please create an [issue here](https://github.com/gravitational/teleport-plugins/issues/new).
+If you have any issues with this plugin please create a [GitHub
+issue](https://github.com/gravitational/teleport-plugins/issues/new).
diff --git a/docs/pages/includes/commercial-prereqs-tabs.mdx b/docs/pages/includes/commercial-prereqs-tabs.mdx
index 69d6c0cea7ec9..7b65d6fd35708 100644
--- a/docs/pages/includes/commercial-prereqs-tabs.mdx
+++ b/docs/pages/includes/commercial-prereqs-tabs.mdx
@@ -2,8 +2,9 @@
-- A running Teleport cluster. For details on how to set this up, see our Enterprise
- [Getting Started](/docs/enterprise/getting-started) guide.
+- A running Teleport cluster, including the Auth Service and Proxy Service. For
+ details on how to set this up, see our Enterprise [Getting
+ Started](/docs/enterprise/getting-started) guide.
- The `tctl` admin tool and `tsh` client tool version >= (=teleport.version=),
which you can download by visiting the
@@ -21,8 +22,9 @@
-- A Teleport Cloud account. If you do not have one, visit the
- [sign up page](https://goteleport.com/signup/) to begin your free trial.
+- A Teleport Cloud account, which includes a running Auth Service and Proxy
+ Service. If you do not have a Teleport Cloud account, visit the [sign up
+ page](https://goteleport.com/signup/) to begin your free trial.
- The `tctl` admin tool and `tsh` client tool version >= (=cloud.version=).
To download these tools, visit the [Downloads](/docs/cloud/downloads) page.
@@ -36,4 +38,4 @@
```
-
\ No newline at end of file
+
diff --git a/examples/resources/plugins/teleport-pagerduty-cloud.toml b/examples/resources/plugins/teleport-pagerduty-cloud.toml
index 1331624d4140a..f9a7899517108 100644
--- a/examples/resources/plugins/teleport-pagerduty-cloud.toml
+++ b/examples/resources/plugins/teleport-pagerduty-cloud.toml
@@ -6,21 +6,7 @@ identity = "/var/lib/teleport/plugins/pagerduty/auth.pem" # Identity file path
[pagerduty]
api_key = "key" # PagerDuty API Key
user_email = "me@example.com" # PagerDuty bot user email (Could be admin email)
-service_id = "PIJ90N7" # PagerDuty service id
-
-[http]
-public_addr = "example.com" # URL on which callback server is accessible externally, e.g. [https://]teleport-pagerduty.example.com
-# listen_addr = ":8081" # Network address in format [addr]:port on which callback server listens, e.g. 0.0.0.0:443
-https_key_file = "/var/lib/teleport/plugins/pagerduty/server.key" # TLS private key
-https_cert_file = "/var/lib/teleport/plugins/pagerduty/server.crt" # TLS certificate
-
-[http.tls]
-verify_client_cert = true # The preferred way to authenticate webhooks on Pagerduty. See more: https://developer.pagerduty.com/docs/webhooks/webhooks-mutual-tls
-
-[http.basic_auth]
-user = "user"
-password = "password" # If you prefer to use basic auth for Pagerduty Webhooks authentication, use this section to store user and password
[log]
output = "stderr" # Logger output. Could be "stdout", "stderr" or "/var/lib/teleport/pagerduty.log"
-severity = "INFO" # Logger severity. Could be "INFO", "ERROR", "DEBUG" or "WARN".
\ No newline at end of file
+severity = "INFO" # Logger severity. Could be "INFO", "ERROR", "DEBUG" or "WARN".
diff --git a/examples/resources/plugins/teleport-pagerduty-self.toml b/examples/resources/plugins/teleport-pagerduty-self.toml
index ad361bfa21672..d935a451fae0b 100644
--- a/examples/resources/plugins/teleport-pagerduty-self.toml
+++ b/examples/resources/plugins/teleport-pagerduty-self.toml
@@ -8,21 +8,7 @@ root_cas = "/var/lib/teleport/plugins/pagerduty/auth.cas" # Teleport cluster C
[pagerduty]
api_key = "key" # PagerDuty API Key
user_email = "me@example.com" # PagerDuty bot user email (Could be admin email)
-service_id = "PIJ90N7" # PagerDuty service id
-
-[http]
-public_addr = "example.com" # URL on which callback server is accessible externally, e.g. [https://]teleport-pagerduty.example.com
-# listen_addr = ":8081" # Network address in format [addr]:port on which callback server listens, e.g. 0.0.0.0:443
-https_key_file = "/var/lib/teleport/plugins/pagerduty/server.key" # TLS private key
-https_cert_file = "/var/lib/teleport/plugins/pagerduty/server.crt" # TLS certificate
-
-[http.tls]
-verify_client_cert = true # The preferred way to authenticate webhooks on Pagerduty. See more: https://developer.pagerduty.com/docs/webhooks/webhooks-mutual-tls
-
-[http.basic_auth]
-user = "user"
-password = "password" # If you prefer to use basic auth for Pagerduty Webhooks authentication, use this section to store user and password
[log]
output = "stderr" # Logger output. Could be "stdout", "stderr" or "/var/lib/teleport/pagerduty.log"
-severity = "INFO" # Logger severity. Could be "INFO", "ERROR", "DEBUG" or "WARN".
\ No newline at end of file
+severity = "INFO" # Logger severity. Could be "INFO", "ERROR", "DEBUG" or "WARN".