How to Set Up Login Credentials for Weaviate Vector DB in Development Environment?

Support
1

Hello Weaviate Community,

I am currently working on setting up a Weaviate Vector DB in our development environment. As part of this setup, I need to configure login credentials to ensure secure access to the database. In our current setup, we use a username and password for logging into our Oracle database, and we store these credentials securely in AWS Secrets Manager.

I am looking for guidance on how to implement a similar setup for Weaviate. Here are a few specific questions I have:

  1. Configuration Files: Which configuration files need to be modified to set up login credentials for Weaviate? Are there any specific parameters that need to be added or updated?
  2. Environment Variables: Is it possible to use environment variables for storing login credentials? If so, what is the recommended way to configure these variables in Weaviate?
  3. AWS Secrets Manager Integration: Can Weaviate integrate with AWS Secrets Manager for storing and retrieving login credentials? If yes, what are the steps to configure this integration?
  4. Authentication Methods: What authentication methods are supported by Weaviate for securing access to the vector database? Are there any preferred methods for a development environment?
  5. Security Best Practices: Are there any security best practices or recommendations for managing and securing login credentials in a development environment, especially when using cloud services like AWS?
  6. Common Pitfalls: What are some common pitfalls or issues that developers might encounter when setting up login credentials for Weaviate, and how can they be avoided?

Any detailed guidance, examples, or references to documentation would be greatly appreciated. Thank you in advance for your assistance!

Best regards

2

Hey!

There are 2 areas you are going to want to potentially explore depending on how you are installing your Weaviate Instance:

  1. If you are using Docker, you will want to reference our documentation here:Authentication | Weaviate
  2. If you are using Kubernetes you will want to reference our documentation here: Kubernetes | Weaviate

These both go over setting up the authentication which does utilizing env variable in either your docker compose or values.yaml file.

You can integrate with AWS Secretes manager by setting the env variables in your docker compose or your values file, then configure the module accordingly. We do have that documented here: Text Embeddings | Weaviate

The methods we offer are API-key or OIDC authentication which is gone over in the above docs!

As far as best practices, I would ensure you are utilizing your Read-only keys for any client that is only performing read operations on your objects and that you utilize ENV variables when possible.

Common pitfalls I’ve seen are users using an admin key for CRUD operations, and not Cycling the API keys when users should no longer have access to them.

I hope this helps!

Joe
Support Engineer
Weaviate

3

Thank you so much. We will be able to figure it out using your help.

1 Like
4

Hi @Joe,
If I want to use API key based authentication, can i use it if I am connecting to weaviate locally.
client = weaviate.connect_to_local()
where i am not using any weaviate url, username or password.
How we can secure weaviate db when we are connecting using docker locally.

thank you in advance.

5

hi @Rohini_vaidya !!

Both connect_to_local and connect_to_weaviate_cloud will use, under the hood, the connect_to_custom.

This means that while using connect_to_local, you can overwrite some of it’s parameters.

For example, this is how you can connect to a custom Weaviate cluster:

client = weaviate.connect_to_custom(
    http_host=http_host,        # Hostname for the HTTP API connection
    http_port=443,              # Default is 80, WCD uses 443
    http_secure=True,           # Whether to use https (secure) for the HTTP API connection
    grpc_host=grpc_host,        # Hostname for the gRPC API connection
    grpc_port=443,              # Default is 50051, WCD uses 443
    grpc_secure=True,           # Whether to use a secure channel for the gRPC API connection
    auth_credentials=Auth.api_key(weaviate_api_key),    # API key for authentication
)

So in your case, you can just pass auth_credentials to your client instantiation:

client = weaviate.connect_to_local(
    auth_credentials=Auth.api_key(weaviate_api_key)
)

Let me know if that helps!

Thanks!

6

Thank you @DudaNogueira
This works for me.

Thank you quick response !

1 Like
7

Any time, my friend.

We are here to help :slight_smile:

Happy coding :flexed_biceps:

1 Like
8

Hi @DudaNogueira,

I am setting up authentication for Weaviate using API keys. Here’s what I have configured in my docker-compose

AUTHENTICATION_ANONYMOUS_ACCESS_ENABLED: 'false'  
AUTHENTICATION_APIKEY_ENABLED: 'true'  
AUTHENTICATION_APIKEY_ALLOWED_KEYS: 'api_key1,api_key2'  
AUTHENTICATION_APIKEY_USERS: 'user1,user2'

For connecting to Weaviate, I am using the following approach

client = weaviate.connect_to_local(  
    auth_credentials=Auth.api_key(weaviate_api_key)  
)

I have a few doubts regarding access control:

  1. If I have multiple users (e.g., user1 and user2), each with a separate API key, does Weaviate ensure that user1 can access only their own data, or will they have access to data from user2 as well?
  2. If this setup does not enforce access control at the data level, what would be the recommended approach to ensure that each user can only access and manage their own data in Weaviate?

Any guidance on this would be greatly appreciated!

Thanks!

9

Hi @Rohini_vaidya !

RBAC, or Role Based Access Control was just implemented in our 1.29 version, the latest as I write.

You can find the documentation here:

And yes, we are working on a “dynamic” RBAC that doesn’t require to restart the server to add/change/remove new users. :see_no_evil_monkey:

Let me know if this help!

11

Thank you @DudaNogueira !!!

1 Like