Authentication overview
Pinecone uses API keys and an environment string for authenticating requests to its vector database. This system allows client applications to establish a secure, authorized connection with specific Pinecone projects and indexes. Each API key is generated and managed within the Pinecone console and is associated with a particular project and environment.
When an application makes a request to the Pinecone API, it includes the API key and environment string as part of the request headers or configuration. The Pinecone service then validates these credentials against its records to determine if the request is authorized. This mechanism is fundamental for controlling access to your vector indexes, protecting data, and isolating different projects or environments.
The authentication process is stateless, meaning each request must carry the necessary credentials. This simplifies client-side implementation by removing the need for session management but emphasizes the importance of secure handling and transmission of API keys.
Supported authentication methods
Pinecone primarily supports API key-based authentication. This method is common across many modern APIs due to its simplicity and effectiveness for programmatic access. There are no alternative methods such as OAuth 2.0 or mutual TLS directly supported for authenticating API requests to the Pinecone service at the time of writing. However, applications can integrate Pinecone into systems that use these other authentication mechanisms for their own user access, such as a web application authenticating users via OAuth 2.0 and then using its stored Pinecone API key to interact with Pinecone.
The API key functions as a bearer token, which is typically sent in the Api-Key HTTP header for REST API calls. Along with the API key, the client must also specify the Pinecone environment (e.g., us-west-2) to route the request correctly to the associated project and index instances. This environment string is part of the API endpoint itself, or a configuration parameter in the SDKs.
Authentication method summary
| Method | When to Use | Security Level |
|---|---|---|
| API Key (and Environment) | All programmatic access to Pinecone API, SDKs, and CLI tools. | Standard; relies on secure key management and transmission over HTTPS. |
Getting your credentials
Accessing your Pinecone API key and environment string requires logging into the Pinecone console. Once logged in, these credentials can be found and managed within your project settings. Each Pinecone project will have one or more API keys associated with it, which can be revoked or regenerated as needed for security purposes.
- Log In to Pinecone Console: Navigate to the Pinecone homepage and log in to your account.
- Access API Keys: From the dashboard, typically look for a section related to "API Keys" or "Project Settings." Pinecone's official documentation provides specific navigation paths, often under the "API Keys" menu item.
- Retrieve API Key: Your active API keys will be displayed. You can copy an existing key or generate a new one if necessary. It's crucial to copy the key immediately after generation, as it might not be fully displayed again for security reasons.
- Identify Environment String: Alongside your API key, your environment string (e.g.,
us-west-2-gcp-freeor similar region identifier) will be provided. This string indicates the cloud region and cluster your project resides in.
For development and testing, you can directly paste these keys into your code or environment configuration. For production deployments, it is strongly recommended to use environment variables or a secrets management service to store and inject these credentials securely.
Authenticated request example
Authenticating with Pinecone typically involves initializing the Pinecone client with your API key and environment. The following examples demonstrate how to do this using the Pinecone Python and Node.js SDKs, which are among the Pinecone primary language examples.
Python SDK example
import os
from pinecone import Pinecone, Index, PodSpec
# It's best practice to load credentials from environment variables
api_key = os.environ.get("PINECONE_API_KEY")
environment = os.environ.get("PINECONE_ENVIRONMENT")
# Initialize Pinecone client
pc = Pinecone(api_key=api_key, environment=environment)
# Example: List existing indexes to verify authentication
try:
print(f"Pinecone client initialized. Existing indexes: {pc.list_indexes()}")
except Exception as e:
print(f"Authentication failed or error occurred: {e}")
Node.js SDK example
import { Pinecone } from '@pinecone-database/pinecone';
// Load credentials from environment variables for security
const apiKey = process.env.PINECONE_API_KEY;
const environment = process.env.PINECONE_ENVIRONMENT;
// Check if environment variables are set
if (!apiKey || !environment) {
console.error('PINECONE_API_KEY and PINECONE_ENVIRONMENT must be set as environment variables.');
process.exit(1);
}
// Initialize Pinecone client
const pc = new Pinecone({
apiKey: apiKey,
environment: environment,
});
// Example: List existing indexes to verify authentication
async function listIndexes() {
try {
const indexes = await pc.listIndexes();
console.log('Pinecone client initialized. Existing indexes:', indexes);
} catch (error) {
console.error('Authentication failed or error occurred:', error);
}
}
listIndexes();
In both examples, the credentials are retrieved from environment variables. This method is preferred over hardcoding them directly into the source code, especially for production environments, as it reduces the risk of exposure.
Security best practices
Securing your Pinecone API keys is critical to maintaining the integrity and privacy of your vector data. Adhering to established security practices for API keys is essential.
-
Use Environment Variables: Never hardcode API keys directly into your application's source code. Instead, store them as environment variables (e.g.,
PINECONE_API_KEY,PINECONE_ENVIRONMENT) and load them at runtime. This practice prevents keys from being exposed in version control systems like Git and makes it easier to manage credentials across different deployment environments. -
Secrets Management Services: For production deployments, integrate with dedicated secrets management services like AWS Secrets Manager, Google Cloud Secret Manager, or Azure Key Vault. These services provide secure storage, retrieval, and rotation of credentials, enhancing overall security posture.
-
Principle of Least Privilege: While Pinecone API keys currently grant full access to a project, apply the principle of least privilege in your broader system architecture. Ensure that only necessary components of your application have access to the Pinecone API key, and restrict user permissions within your Pinecone account to what is strictly required.
-
Regular Key Rotation: Periodically rotate your API keys. This practice minimizes the window of opportunity for an exposed key to be exploited. Pinecone allows you to generate new keys and revoke old ones through its console.
-
Secure Transmission (HTTPS): All communication with the Pinecone API occurs over HTTPS by default. Ensure your client applications always use HTTPS endpoints to encrypt data in transit, protecting your API key and data from eavesdropping. The IETF RFC 7235 on Authentication outlines the importance of secure transmission for credentials.
-
Monitor for Suspicious Activity: Regularly monitor your Pinecone project for unusual activity, such as unexpected query patterns or resource usage. While Pinecone does not provide granular access logs for API key usage directly to users, unusual resource consumption could indicate a compromised key.
-
Source Code Scanners: Use static analysis tools and source code scanners in your CI/CD pipelines to detect accidental exposure of API keys and other sensitive information within your codebase before deployment.
-
Restrict Access to Pinecone Console: Limit who has access to the Pinecone console, where API keys are managed. Implement strong authentication methods (e.g., multi-factor authentication) for all user accounts with console access.