Skip to content

Commit 8b5b2a7

Browse files
updating keyring documentation (#61)
1 parent 99fb695 commit 8b5b2a7

File tree

6 files changed

+343
-287
lines changed

6 files changed

+343
-287
lines changed

fern/docs/pages/references/keyrings.mdx

Lines changed: 0 additions & 285 deletions
This file was deleted.
Lines changed: 43 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,43 @@
1+
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.
2+
3+
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.
4+
5+
## Snap-in secrets
6+
7+
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.
8+
9+
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.
10+
11+
To create a snap-in secret with the CLI, run the following command:
12+
13+
```bash
14+
echo \"<SECRET>\" | devrev developer_keyring create snap-in-secret <KEYRING NAME>
15+
```
16+
17+
## OAuth secrets
18+
19+
The OAuth secret is specifically designed to store OAuth client credentials securely. It requires two fields:
20+
21+
* `client_id`: The client ID provided by the OAuth provider.
22+
* `client_secret`: The client secret provided by the OAuth provider.
23+
24+
To create an OAuth secret with the CLI, run the following command:
25+
26+
```bash
27+
echo '{"client_id":"<CLIENT ID>","client_secret":"<CLIENT SECRET>"}' | devrev developer_keyring create oauth-secret <KEYRING NAME>
28+
```
29+
30+
## Developer keyrings in the snap-in manifest
31+
32+
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.
33+
34+
Syntax:
35+
36+
```yaml
37+
developer_keyrings:
38+
- name: <name of the keyring>
39+
description: <description of the keyring>
40+
display_name: <display name of the keyring>
41+
```
42+
43+
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.
Lines changed: 44 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,44 @@
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

Comments
 (0)