Is integration key really a secret?

In https://community.pagerduty.com/forum/t/event-api-integration-key-does-it-need-to-be-a-secret/429 it says integration key should be treated like credential. However in the Amazon Cloud Watch Integration Guide, it tells the reader to put the integration URL, which includes integration key, into SNS’ “Endpoint” field. So anyone going to the SNS console can see the integration URL as plain text.

So I am wondering, if the recommendation is to put the integration URL as some plain text property in SNS, does it need to be a secret?

Hi Alvin! This is a great question!

There’s a few different pieces of data that act like keys in the PagerDuty platform, and they allow for different components to be authorized. The two secret types interact with different aspects of our API, the events API and the REST API.

Integration keys, which are also sometimes referred to in the docs as “routing keys” are single-function endpoint ids for receiving alerts and events. They do get entered into UIs on other tools for many/most of the integrations that feed data into PagerDuty. They have a very limited use - they tell PagerDuty where to send an alert or event (a service or a rule). They can’t be used to change anything on the platform. So they are sensitive but not secret in a way that you’d want to prevent everyone in your org from accessing them in the average case, but you don’t want them shared publicly or checked into a github repo.

The other keys are the API Access Keys and User Tokens that provide the ability to make changes to the objects in your PagerDuty account - services, rules, users, teams, escalation policies, etc - and those should be treated as true secret credentials and stored in your vault. You won’t use these keys in integrations that send data TO PagerDuty, but they are required for extensions that receive data FROM PagerDuty and can interact with it - like Slack or ServiceNow.

Hope that helps. Happy to chat more if you have more questions!