|
| 1 | +Keyrings provide a secure way to manage credentials for external services used within your DevRev snap-in. This eliminates the need to store sensitive information like passwords or access tokens directly in your code or configuration files, improving overall security. |
| 2 | + |
| 3 | +Traditionally, developers might store these credentials directly in their snap-in's code. This poses a significant security risk. If someone gains access to your code, they could also steal these sensitive credentials. |
| 4 | + |
| 5 | +Keyrings provide a secure alternative. By storing credentials separately from your code, you ensure they remain hidden and inaccessible even if the code is compromised. This strengthens the overall security of your snap-in. |
| 6 | + |
| 7 | +Imagine you're building a DevRev snap-in that helps manage your marketing campaigns across different platforms. This snap-in might need to connect to various external services like Facebook Ads, Mailchimp, and a project management tool like Asana. |
| 8 | + |
| 9 | +Here's where DevRev keyrings come in: |
| 10 | + |
| 11 | +You can define keyrings within your snap-in manifest for each external service you need to connect to. |
| 12 | +During installation, users will be prompted to provide their credentials for each keyring (think of it like securely logging in to each service through your snap-in). These credentials are then stored securely in the keyrings. |
| 13 | +When your snap-in needs to interact with a specific service, it retrieves the necessary credentials from the corresponding keyring (see snap-in resources) instead of your code. This keeps your sensitive information safe and isolated. |
| 14 | + |
| 15 | +Think of keyrings as secure vaults within your snap-in, acting as a middleman between your snap-in and the external services it connects to. This ensures both security and a smooth user experience during installation. |
| 16 | + |
| 17 | +## Supported credential types |
| 18 | + |
| 19 | +* **OAuth 2.0 :** Streamline connections with popular services like Slack and Jira using pre-defined OAuth keyrings. |
| 20 | +* **Secrets:** Store various secret configurations, including personal access tokens (PATs) and multi-field tokens (JSON) for broader service integrations. |
| 21 | + |
| 22 | +## Access levels |
| 23 | + |
| 24 | +- **User level:** Securely store credentials specific to individual users, allowing them to connect their own accounts to external services through your snap-in. |
| 25 | +- **Organization level:** Share credentials across your organization for access to a single, shared account for an external service. |
| 26 | + |
| 27 | +## Syntax |
| 28 | +A syntax for defining keyrings within your snap-in manifest: |
| 29 | + |
| 30 | +```yaml |
| 31 | +keyrings: |
| 32 | + organization: |
| 33 | + - name: <name of the keyring> |
| 34 | + display_name: <display name of the keyring> |
| 35 | + description: <description of the keyring> |
| 36 | + types: |
| 37 | + - <id of the keyring type> |
| 38 | + user: |
| 39 | + - name: <name of the keyring> |
| 40 | + display_name: <display name of the keyring> |
| 41 | + description: <description of the keyring> |
| 42 | + types: |
| 43 | + - <id of the keyring type> |
| 44 | +``` |
0 commit comments