Skip to content

updating keyring documentation #61

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 13 commits into from
Jun 21, 2024
285 changes: 0 additions & 285 deletions fern/docs/pages/references/keyrings.mdx

This file was deleted.

43 changes: 43 additions & 0 deletions fern/docs/pages/references/keyrings/developer_keyring.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,43 @@
In addition to keyrings for storing user or organization credentials, DevRev also offers a special type called developer keyrings. These keyrings cater specifically to developers during the snap-in creation process.

Unlike other keyrings that store user credentials, developer keyrings are designed to hold sensitive information needed by the developer during development and execution of any particular task. These secrets are provided by you, the developer, during the creation of a snap-in version. They are not exposed to users and are stored separately from the snap-in itself.

## Snap-in secrets

A snap-in secret is a simple way to store any plain text secret your snap_in requires. It's ideal for sensitive information that doesn't require complex formatting.

To create a snap-in secret in the UI, go to the snap-in page **Connection** tab and find the `snap_in_secret` keyring type.

To create a snap-in secret with the CLI, run the following command:

```bash
echo \"<SECRET>\" | devrev developer_keyring create snap-in-secret <KEYRING NAME>
```

## OAuth secrets

The OAuth secret is specifically designed to store OAuth client credentials securely. It requires two fields:

* `client_id`: The client ID provided by the OAuth provider.
* `client_secret`: The client secret provided by the OAuth provider.

To create an OAuth secret with the CLI, run the following command:

```bash
echo '{"client_id":"<CLIENT ID>","client_secret":"<CLIENT SECRET>"}' | devrev developer_keyring create oauth-secret <KEYRING NAME>
```

## Developer keyrings in the snap-in manifest

Once you've created the keyring, you can use it in your snap-in by referencing the keyring name in the snap-in manifest file.

Syntax:

```yaml
developer_keyrings:
- name: <name of the keyring>
description: <description of the keyring>
display_name: <display name of the keyring>
```

When creating a new `snap_in_version` using the developer tools, you will be prompted to provide the values for the declared developer keyrings. This ensures that the sensitive information is securely stored and accessible to your snap-in at runtime.
44 changes: 44 additions & 0 deletions fern/docs/pages/references/keyrings/introduction.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,44 @@
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.

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.

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.

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.

Here's where DevRev keyrings come in:

You can define keyrings within your snap-in manifest for each external service you need to connect to.
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.
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.

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.

## Supported credential types

* **OAuth 2.0 :** Streamline connections with popular services like Slack and Jira using pre-defined OAuth keyrings.
* **Secrets:** Store various secret configurations, including personal access tokens (PATs) and multi-field tokens (JSON) for broader service integrations.

## Access levels

- **User level:** Securely store credentials specific to individual users, allowing them to connect their own accounts to external services through your snap-in.
- **Organization level:** Share credentials across your organization for access to a single, shared account for an external service.

## Syntax
A syntax for defining keyrings within your snap-in manifest:

```yaml
keyrings:
organization:
- name: <name of the keyring>
display_name: <display name of the keyring>
description: <description of the keyring>
types:
- <id of the keyring type>
user:
- name: <name of the keyring>
display_name: <display name of the keyring>
description: <description of the keyring>
types:
- <id of the keyring type>
```
Loading
Loading