Implement Isolated Tenants for User-Specific Configurations

[shaker402]

Description:

Currently, SocFortress Copilot uses a single set of connector configurations (e.g., WAZUH) for all users. This means that all users share the same configuration, regardless of their role or needs.

Problem:

This approach creates limitations and potential security risks:

• Lack of Isolation: Users cannot have customized configurations tailored to their specific needs.
• Limited Scalability: As the number of users grows, managing a single set of configurations becomes complex.
• Security Concerns: If one user accidentally modifies or exposes the configuration, it could impact all users.

Proposed Solution:

Introduce isolated tenants in the system. Each user (or group) can have their own tenant with dedicated connector configurations. This will provide:

• Improved Security: Users will only access and modify configurations for their assigned tenant, enhancing data security.
• Increased Flexibility: Users can have customized configurations based on their specific needs and roles.
• Enhanced Scalability: The system can easily accommodate a growing user base with isolated tenant configurations.

Implementation Details:

• Introduce a new table in the database to store tenant-specific configurations (e.g., WAZUH URL, credentials).
• Modify user registration to create a new tenant entry for each user with initial configurations.
• Update connector code (WAZUH and others) to retrieve configuration details based on the logged-in user's tenant ID (stored in the JWT token).
• Implement proper access control mechanisms to restrict unauthorized access to other tenants' configurations.

Benefits:

• Improved user experience with tailored configurations.
• Enhanced security through tenant isolation.
• Increased scalability for future growth.

By implementing isolated tenants, SocFortress Copilot can provide a more secure, scalable, and user-friendly experience for its users.

[shaker402]

in simple. implementing tenant isolation in SocFortress Copilot baes on user profile, and RBAC WITH three levels in the futures

[shaker402]

dear @taylorwalton ,

I'm writing to you today with a request for your expertise on the socfortress-CoPilot project. I've been a long-time working of your project and now , I am required to present it to my senior management.

The key feature I'm aiming to showcase is multi-tenancy. However, I've encountered some challenges in implementing this functionality. I've explored various approaches, including:

Separate databases per user admin Schema-based separation External Authentication Service (LDAP/Active Directory) Unfortunately, I haven't been able to successfully implement any of these solutions yet.

Your guidance and insights on implementing multi-tenancy within socfortress-CoPilot would be invaluable. Understanding the best approach for my specific use case would significantly enhance my presentation and showcase the project's true potential.

I understand your time is valuable, but any suggestions or resources you could point me towards would be immensely appreciated.

Thank you for your time and consideration.

Shakr Saif

[taylorwalton]

Hey @shaker402 it sounds like you are looking for multi-tenancy within Co-Pilot with the ability to configure individual connectors per tenant. Unfortunately what you are looking for is out of scope of our current plans for Copilot. While it is true Copilot is set to manage a multi-tenant SIEM stack (designed as the one we provide to our clients / video series) it is not designed to be multi-tenanted itself. It is assumed that users who are provided access to CoPilot manage all customers provisioned / onboarded via CoPilot. As of now this is our focus, but perhaps as the app becomes more mature, rbac can be more finely detailed. Unfortunately we just dont have the resources available to us to undergo this task at the moment