ChatGPT for DevOps
Complex actions. Simple conversations
Security measurements
Kubiya has integrations with identity providers such as OKTA and Active Directory to authenticate the user every time he converse with Kubiya.
For every actions executed we check the user’s RBAC policy in Kubiya.
Kubiya can also pull groups and use that as a way to manage access.
Finally each action that is triggered is audited and stored in logs with the relevant user ID. Those logs can be streamed into your logging system.
Introducing Local Runners, your key to executing secure operations with ease. Installed within your infrastructure, they provide seamless orchestration of server-less "action stores". Capable of running various actions and queries directly from your setup, they eliminate the need to share sensitive data. Offering automatic scaling and monitoring, Local Runners redefine security and scalability in task management.
Local operators communicate with your private Kubiya namespace using an encrypted tunnel protocol called Inlet. Each runner has its own tunnel and customers may set up multiple tunnels for multiple runners if additional separation is required between departments or environments.
Kubiya assumes all data is highly sensitive and always strives to use the best security practices and encryption technologies to protect it.
Data in transit is encrypted using TLS.
Temporary user tokens are used to authenticate every user message. Tokens are removed once TTL has reached.
Knowledge entries include include the vector, not the document itself. Each organization has a unique ID in the vector database.
Finally, all stored data is encrypted.
Whether you are in a regulated sector or not, every request in Kubiya is audited with user IDs to any action can be traced back to the individual user.
The data is encrypted and can be streamed to your logging system.
Kubiya has a robust access control policy engine that defines which users or groups have access to what workflows.
An admin can define different policies (e.g AWS, CI, Kuberenetes, DevOps, data science) and assign different administrators to each policy. Administrators can add/remove access from users or groups. Admins will also approve requests for temporary or permanent access or assign requests to other users in the Slack workspace.
If your organization users Open Policy Agent (OPA), Kubiya can inherit policies from OPA .
Deployment modes
At a high-level Kubiya’s architecture includes 3 main components
Actions
All actions get triggered through a local light-weight operator that we install inside your network. You have full control over the operator and which actions it can perform and which resources it has access to. Kubiya cannot perform any action remotely
Large Language Models
At the core of what we do is a combination of large language models that use to understand conversations, generate responses and much more, This is our IP.
Each customer has its own namespace. Data from one namespace does not get shared in other namespaces.
Databases
We use various databases to store data. The key one is a vector database that holds the embeddings. You actual docs are not stored inside Kubiya.
Organizations can be separated by a logical separation or a totally separate database. You can also host the vector database yourself.
Do you send data to ChatGPT?
While we coin the term “ChatGPT for DevOps”, we don’t use ChatGPT in our product with one exception. We provide a ChatGPT-like experience. We only use OpenAI API to power a the conversation. Until we have all the relevant context, nothing gets sent to your platforms.
