[title] Kubeark Actions [path] Automation Menu/Workflows/About Nodes/Actions/ This category offers you a suite of predefined operations crafted with precision by Kubeark for Kubernetes and infrastructure management. These predefined Actions are designed to simplify the workflow creation, providing out-of-the-box components for common tasks that you can readily incorporate into your processes. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/jgYcD7gEG2T-wPgpZuOr8_image.png) :::ExpandableHeading ## Add Kubeark Cluster The "Add Kubeark Cluster" is a specialized action dedicated to adding a Kubernetes cluster to the Kubeark workflow. Here's a breakdown of the configuration available configuration options: - **Name**: The unique identifier for this node in the workflow. - **Condition**: `Condition` - A field where you can define a condition that must be met for this node to execute, allowing for conditional logic in your workflow. - **On Error**: `None` - Determines the behavior if an error occurs while attempting to add the cluster. It seems that currently, there's no action specified for error handling. - **Vault**: `Scopes` - Indicates a secure storage location for sensitive information. "Scopes" may refer to the specific permissions or areas this node can access within the vault. - **Input**: - **Api Token**: `Api Token` - A place to enter the API token that will authenticate the action with the necessary permissions to add a cluster. - **Cluster**: - **Name**: `Name` - The name you want to assign to the new Kubernetes cluster within Kubeark. - **Description**: `Details` - A field for entering a description of the cluster, which could include its purpose, configuration details, or other relevant information. - **Owner**: `Owner` - The entity or user that owns or is responsible for the Kubernetes cluster. - **Active**: `No` - A toggle to specify whether the cluster should be immediately active after addition. - **Prometheus URL**: `Prometheus URL` - The URL to the Prometheus instance associated with the cluster, used for monitoring and metrics collection. - **Usage URL**: `Usage URL` - The URL that provides information on the utilization or other statistics for the cluster. - **Kubeconfig**: - **File Upload / Text**: - This option allows for either uploading a kubeconfig file or providing its contents directly in text format. The kubeconfig is necessary for Kubeark to interact with the Kubernetes cluster, containing details like cluster server addresses, user credentials, and context. - **Upload Config File**: - A button or switch to upload the kubeconfig file directly to the node's configuration. When this node is executed, it will carry out the process of integrating a new Kubernetes cluster into the Kubeark environment using the provided details and configurations. This action simplifies and automates the cluster addition process, making it an essential part of managing multiple clusters within the Kubeark platform. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/U2WfRSDgJUArq8b_qkwL5_image.png) ::: :::ExpandableHeading ## Create Deployment The "Create Deployment" is a node specifically designed to automate the deployment of applications or services in your workflow. Here's what each configuration option means: - **Name**: Unique identifier for this particular deployment node within the workflow. - **Condition**: A field to specify any prerequisites that must be met before this node can run. If a condition is given, the deployment will proceed only when it evaluates to true. - **On Error**: Determines the workflow's response when an error occurs during the deployment. Options could include retrying the deployment, moving to another task, or stopping the workflow entirely. - **Vault**: Secure storage for sensitive data needed for the deployment. Please refer to [Local Vault](docId:6UOO8pp2iYgibUmgRCNwi) - **Input**: - **Wait For Result**: Indicates whether the workflow should pause until the deployment is confirmed successful or not. - **Api Token**: The token for authenticating with the API that will perform the deployment. - **Time Out**: Sets a limit on how long the node should wait for the deployment to complete before timing out. - **Deployment**: - **Name**: The name to be assigned to the deployment. - **Description**: A detailed description of the deployment for identification or documentation purposes. - **Owner**: The person or entity responsible for this deployment. - **Tags**: used for labeling or categorizing the deployment within the system for easier searching or sorting. - **Template Id**: Refers to an identifier for a predefined deployment template, if applicable. - **Cluster Id**: The identifier for the Kubernetes cluster where the deployment should occur. - **Namespace**: Kubernetes namespace where the deployment should be created. - **Grace Time**: An additional period allowed after the deployment, possibly for the service to become stable before proceeding with the workflow. - **Environnement Action**: The type of action to take within the deployment environment. - **Additional Parameters**: A section to input any additional deployment parameters in YAML format, allowing for complex configurations. - **Sensitive Parameters**: A designated space for parameters that are sensitive and require secure handling, such as passwords or private keys. When this node is executed, it will automate the process of creating a new deployment according to the parameters and conditions specified. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/1sUfFrmd05NXtpLiNycRF_image.png) ::: :::ExpandableHeading ## Create Infra Deployment ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/7zXwxikJO6xfmjb7TetrT_image.png) ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/d1dcMae1FffD9bfrMkmb9_image.png) ::: :::ExpandableHeading ## Create Infra Template ::: :::ExpandableHeading ## Create Template ::: :::ExpandableHeading ## Delete Deployment ::: :::ExpandableHeading ## Delete Infra Deployment ::: :::ExpandableHeading ## Delete Kubeark Cluster ::: :::ExpandableHeading ## Get Deployment ::: :::ExpandableHeading ## Get Infra Deployment ::: :::ExpandableHeading ## Get Kubeark Cluster ::: :::ExpandableHeading ## List Infra Deployments ::: :::ExpandableHeading ## Update Deployment ::: :::ExpandableHeading ## Update Template ::: [title] Architecture [path] / [title] Getting Started [path] / [title] Email stage [path] Product Guide/Organization Administration/Untitled/Untitled/ The email stage can be used for email verification, and the background worker will send an email using the specified connection details. If an email cannot be delivered, the delivery is automatically retried periodically. The default behavior is to send the email to the currently pending user, but this can be overridden by setting the `email` in the plan's context to another email address, see below: ```text request.context["flow_plan"].context["email"] = "foo@bar.baz" # Or get it from a prompt # request.context["flow_plan"].context["email"] = request.context["prompt_data"]["email"] # Or another user attribute # request.context["flow_plan"].context["email"] = request.context["pending_user"].attributes.get("otherEmail") return True ``` Custom email templates can also be used, to leverage your own design or layout. ::::Tabs :::Tab{title="docker-compose"} By placing templates in the `custom-templates` folder and selecting the template when creating/editing an email stage. If the template is not visible, the worker logs should be checked. ::: :::Tab{title="Kubernetes"} Create a ConfigMap with your email templates: \{% code overflow="wrap" %} ```yaml apiVersion: v1 kind: ConfigMap metadata: name: authentik-templates namespace: authentik data: my-template.html: | ... ``` \{% endcode %} Then, in the helm chart add this to your `values.yaml` file: ```yaml volumes: - name: email-templates configMap: name: authentik-templates volumeMounts: - name: email-templates mountPath: /templates ``` ::: :::: ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/F-KGDAwpnyl6KavacrJDZ_create-eml-stage.jpeg) [title] Users [path] Product Guide/Organization Administration/ The Users menu allows you to define the Access Management within the organization settings. Go to User Management and select `Users` The Access Management functionality within the Users menu is based on **Role Based Access Control (RBAC)**, a popular access control model in which access to resources is determined by a user's role within an organization. With RBAC, you can create roles and permissions with high granularity, providing fine-grained control over who has access to what resources within the platform. This feature is especially important in enterprise environments where security and access control are critical concerns.\\ ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/JJ0Uo1rgDeP4MuoHQNFDF_image.png) [title] Kubernetes [path] Environments Menu/ **Welcome to the Kubernetes section, where orchestration meets efficiency. This dedicated space focuses primarily on our specialized Kubernetes Templates designed to efficientize your container orchestration journey.** *** As you navigate through this section, you'll encounter specially designed templates, each tailored to optimize the deployment processes within the Kubernetes environment.  Whether you aim to harness the power of containerized applications, achieve optimal resource allocation, or explore the scalability intrinsic to Kubernetes, this section will offer a detailed guide. ## About the module  The Kubernetes menu can be found under the main Environments section of the Kubeark platform. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/NylB8icdVlhcTy8VNu4IX_image.png) In the Kubernetes menu of Kubeark, users have access to dedicated sections specifically designed for configuring and managing Templates, Template Groups, and Deployments. This menu is intuitively organized to facilitate easy navigation and management of these components. Templates (Template Groups) are essential for defining the standard configurations for your Kubernetes resources, while the Deployments section allows for the execution and monitoring of these configurations in a live environment. This arrangement ensures that users can efficiently handle the lifecycle of their Kubernetes resources, from initial configuration to deployment and ongoing management, all within a well-structured and user-friendly interface. - [Template Groups](docId\:K_kBPnulstc8byJkKHTtX) - [Deployments (Kubernetes)](docId:7WZfju1gVMXL7sbQckKoW) [title] Kubey AI [path] Automation Menu/Workflows/The Workflow Editor/ Kubey AI, an important feature available on the Workflows page, represents a significant advancement in automation technology. This tool empowers users to generate sophisticated workflows effortlessly through natural language input. By simply describing the desired automation task in plain text, users can leverage Kubey AI to create fully functional workflows that integrate seamlessly with various systems. Key capabilities of Kubey AI include: **Natural Language Processing**: Kubey AI interprets user instructions provided in natural language, converting them into precise, executable workflows. This eliminates the need for intricate coding or detailed technical knowledge, making advanced automation accessible to all users. **Automated Integration:** The feature supports automatic integration with well-known systems, ensuring that the generated workflows can interact with existing platforms and tools without requiring additional configuration or setup. **Efficient Workflow Generation: **Users can define complex automation tasks quickly. For instance, a user can create a simple prompt in natural language, and Kubey AI will create the necessary steps to achieve this, including setting up variables, making HTTP requests, and executing Python scripts for email distribution etc. ## How to use Kubey AI **Step 1: **Navigate to the `Workflows` section within the `Automation` menu **Step 2:** Select an existing workflow which you want to modify, or simply create a new workflow ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/Jmo-DoPT-opmA7UFyljzF_image.png) **Step 3: **Open the Kubey AI assistant from the bottom left corner of the Workflow editor ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/2oHDhuNslrBog9qT46tee_image.png) **Step 4: **Type in a prompt in natural language and Kubeay AI will create the respective workflow for you *** In the below snapshot, a user inputs a request to "get the latest 10 deals from HubSpot and send them to email via SendGrid." Kubey AI LAM interprets this command and automatically constructs a workflow consisting of: - Defining variables to set up the necessary parameters. - An HTTP request to retrieve the latest deals from HubSpot. - A Python script to send the fetched deals via email using SendGrid. Once you have prompted Kubey AI and received a response, you have several options to utilize the generated result: **1. Create a New Workflow**: You can use the generated code to create an entirely new workflow. This option allows you to build a fresh automation process based on the AI's output, starting from scratch and incorporating the suggested steps and integrations. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/RiSFeC4gyIL0EFJQVdr_A_image.png) **2.** **Insert a Node into an Existing Workflow:** Alternatively, you can integrate the generated result into an existing workflow. This option is useful for enhancing or modifying current automation processes by adding new nodes based on the AI's recommendations. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/7IOU161R6npLOYN5MdsFL_image.png) ### Viewing the Generated Result The generated result can be viewed in two formats, according to your preference: **1. Graph:** View the generated result as a visual workflow, which provides a graphical representation of the steps and nodes involved. This format is intuitive and user-friendly, making it easier to understand the flow of the automation process. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/eVrfokW-3CYUV_CpzHPKP_image.png) **2. Code: **Alternatively, you can view the generated result as code. This format is suitable for users who prefer a detailed, text-based representation of the workflow. It allows for precise modifications and a deeper understanding of the underlying logic. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/j6n0Y-ZnX1KYRc_XDtvGf_image.png) [title] Roles and Permissions [path] Product Guide/Organization Administration/ ### Permissions Permissions are a key security control. In order to protect sensitive information and maintain the integrity of systems, permissions play a fundamental role. By defining what actions or operations a user or process can perform, permissions help to enforce access control and ensure that only authorized individuals have the ability to perform certain tasks. These permissions act as a safeguard, preventing unauthorized access or misuse of resources. In Kubeark, permission types grant users access to different sections of the app and define key allowed actions for the users, such as read, create, update or delete items on the specific section. A role is identified as group of permissions that are grouped under one name. All the roles can be customised. ### Roles During the installation process of the Kubeark platform, an **administrative role** with all permissions is created by default. This allows for an initial level of access control to be established for the administrator, who can then proceed to create custom roles with varying levels of permissions. The custom roles can be tailored to the needs of specific user groups, departments, or projects, enabling a flexible and granular approach to access control. All sections of the web application are structured with the standard Create, Read, Update, and Delete (CRUD) permissions. This allows for precise control over the level of access that each role has to the different sections and features of the web application. The administrator can then assign specific roles to individual users or groups of users, ensuring that only authorized users have access to sensitive data and functionality. Additionally, the Kubeark Platform provides advanced auditing capabilities that allow you to track and record actions performed by users and to gain a better understanding of user activity. This can help you to detect any malicious or accidental actions, as well as to identify any areas where additional controls are required. Overall, the Kubeark Platform's role-based access control system allows you to establish a secure and compliant environment, while also providing the flexibility and granularity that you need to manage access control for a diverse set of users. :::hint{type="info"} The is created during the Kubeark installation process and is the most powerful Account, being authorised to execute all the possible actions in the Kubeark platform. The is a basic permission level needed in order to access the Kubeark Platform. This role can be created, updated, or deleted based on the RBAC Matrix defined by the `global_admin`, `admin`, or `user`. ::: ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/HwUFs6AbHDBZ_HQy8b-kE_crud.jpeg) Below you will find a list of all possible permissions: | **Asset** | **Permissions** | | ---------- | --------------------------------------------------------------------------------- | | Users | - users\_read - users\_create - users\_update - users\_delete | | Roles | * roles\_read * roles\_create * roles\_update * roles\_delete | | Cluster | - cluster\_read - cluster\_create - cluster\_update - cluster\_delete | | Config | * config\_read * config\_create * config\_update * config\_delete | | Deployment | - deployment\_read - deployment\_create - deployment\_update - deployment\_delete | | License | * license\_delete * license\_update * license\_create * license\_delete | | Monitoring | - monitoring\_read - monitoring\_update - monitoring\_create - monitoring\_delete | | Billing | * billing\_read * billing\_update * billing\_create * billing\_delete | | Alerts | - alerts\_read - alerts\_update - alerts\_create - alerts\_delete | | Logs | * logs\_read * logs\_update * logs\_create * logs\_delete | | Webhooks | - webhooks\_read - webhooks\_create - webhooks\_update - webhooks\_delete | [title] Platform Interface [path] Architecture/ The Kubeark Platform web application is designed to provide users with a user-friendly and efficient interface for managing and utilizing the platform's features and functionalities. The application is composed of three main elements: the Platform menu, the Features menu, and the Working area. :::ExpandableHeading ## Platform menu This menu is located at the top of the page and provides users with access to different sections of the platform. This top panel is present on all pages of the Kubeark Platform. The Platform Menu is designed to help users navigate through different clusters, manage their own properties and preferences, and optimize the visual effects of the pages they are viewing. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/UsiUfKl6tiZzNg8eX05uS_image.png) ::: :::ExpandableHeading ## Features menu This menu is also present across all Kubeark Platform pages and offers you the possibilty to navigate through various sections of the platform. This "side bar" displays all the Kubeark menus and functionalities needed to operate the platform. You will find a detailed overview of each of these sections going further. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/Im3LYsM6sGCYOa3rkCpFX_image.png) ::: :::ExpandableHeading ## Working area The Working Area is the central part of the Kubeark Platform web application and is where users interact with the features and functionalities of the platform. This is where the resources accessed through the left side menu are displayed and available for the user to perform their usual actions, depending on the user's rights and permissions. Depending on the user's rights and permissions, the Working Area can display different types of information and resources. For example, users with high-level permissions may have access to more advanced features and functionalities, such as creating and managing custom reports, while users with limited permissions will have access to a more basic set of features and functionalities. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/s_hm-MshPRBa0VWr_cJ5f_image.png) ::: [title] Workspace [path] Automation Menu/ **Kubeark Workspace** redefines the way teams collaborate on automation projects. It's a versatile menu where users can seamlessly invite colleagues, QA testers, and authorized personnel to work collectively on automation initiatives. The Workspace menu within Kubeark is designed to empower users in managing their automation projects with ease and precision. It houses an array of indispensable features that collectively elevate your automation game to new heights. From crafting intricate workflows to ensuring robust security through Vault, the Workspace menu is your one-stop destination for orchestrating seamless automation processes. With the ability to create multiple Workspaces, each containing workflows, vault variables, and triggers, teams gain the agility to manage automation projects efficiently while safeguarding sensitive information like user credentials. The Workspace menu overview: - [Workflows](docId\:K5wX3wwWutvgkjpDRPV_G): At the heart of the Workspace menu lies the Workflows feature, a powerful tool that enables you to design, visualize, and execute complex automation sequences effortlessly. With intuitive drag-and-drop functionality, you can create workflows that cater to your specific needs. - Triggers: The Triggers section within Workspace empowers you to set precise conditions and actions, automating responses to various events or data changes. By defining trigger rules, you can design automations that are efficient and responsive to real-time events. - Cron Jobs: The Workspace menu also offers Cron Jobs, a scheduling feature that allows you to automate tasks at predefined intervals. Whether it's daily backups, weekly reports, or monthly updates, Cron Jobs provide the means to automate these recurring processes with precision. - [Global Vault](docId:2rllb1GL2dwiCGxPEZHM7): Vault provides a secure storage solution for these secrets, allowing you to seamlessly integrate them into your automation workflows without compromising security. - [Logs (Global)](docId\:wj_E8OfITyJdk_1wkeKqR): To maintain transparency and accountability in your automation projects, Workspace offers a Logs section. Here, every action taken within your automation environment is meticulously logged, providing you with a comprehensive record of all activities. From workflow changes to trigger events, the Logs feature ensures that you can trace and analyze the history of your automation efforts. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/-LhlDZIz5uijKnl_lAxY0_image.png) At its core, Kubeark Workspace simplifies collaboration by enabling users to invite team members and allocate precise permissions based on roles. This fine-grained access control ensures that the right individuals have the necessary privileges to contribute to the Workspace's content and automation processes. Vault variables within Workspaces can be utilized across workflows and triggers, making it convenient to manage and share sensitive data securely. :::hint{type="success"} The workspace vault variables can be used in any of its triggers and workflows ::: Kubeark Workspace logs every action taken within its environment. This robust audit trail provides a clear view of all changes, interactions, and activities occurring within a Workspace, promoting accountability and allowing users to track the history of their automation projects. With Kubeark Workspace, teams can collaborate effectively, enhance security, and maintain a comprehensive record of their automation endeavors. :::hint{type="info"} You can create any number of Workspaces that have workflows, vault variables and triggers into it to be able to collaborate and work with sensible information (users, passwords) ::: [title] Stages [path] Product Guide/Organization Administration/Untitled/ Kubeark Identity supports a range of stages, including: - [Captcha stage](docId\:w7tAmeEJe9ZWiZDNb49KF) - [Deny stage](docId\:lxg9qfQ3VSBFUtWnl4HfE) - [Email stage](docId\:TJ5IJ1zs5bSVrncGeggPV) - [Identification stage](docId\:ldjcSgOtEb3SdzJA07mWS) - [Invitation stage](docId\:ie9xyu1C76ig2TtfrU_AK) - [Password stage](docId:9fr8PaZ4T-Q9Xygp3xDvr) - [Prompt stage](docId\:fpR0QBpTqhEjRf4VqgTOW) - [User Delete/Login/Logout stage](docId\:JdMo7OEnRr-28Lbi_dX0D) [title] Functions [path] Automation Menu/ In today’s complex software landscape, integrating products written in various programming languages presents a significant challenge. Kubeark Functions emerge as a powerful solution to this challenge, offering the capability to run functions written in multiple programming languages seamlessly. This feature underscores Kubeark's commitment to flexibility and interoperability, enabling users to deploy functions in diverse environments, including cloud and on-premise, thus avoiding vendor lock-in. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/AO4nboebS__qY0Mn1pJKJ_image.png) ## **Key Features of Kubeark Functions** 1. **Multi-Language Support**: - Kubeark Functions are designed to operate with a multitude of programming languages, facilitating integration across different software platforms. - This versatility ensures that functions written in various languages can be executed within the Kubeark ecosystem without the need for extensive rewrites or adaptations. 2. **Kubernetes Pod Deployment**: - Functions are deployed in Kubernetes pods, capitalizing on the robustness and scalability of Kubernetes infrastructure. - This deployment strategy enhances the reliability and efficiency of function execution, ensuring optimal resource utilization and management. 3. **Custom Resource Allocation**: - Kubeark allows users to specify the resources allocated for running each function. - This flexibility in resource management enables the optimization of performance based on the needs of the function and the overall system load. 4. **Environment Agnostic Execution**: - Kubeark Functions can be executed in any environment, whether it’s a cloud platform or an on-premise setup. - This feature is particularly beneficial for organizations aiming to maintain operational flexibility and avoid dependence on a single vendor or cloud provider. 5. **Solving Integration Challenges**: - By enabling the execution of functions across various programming languages and environments, Kubeark Functions address a core challenge in modern software integration. - This capability significantly simplifies the process of integrating disparate software systems, fostering a more cohesive and efficient digital ecosystem. ## How to create a Function in Kubeark Creating a Function in Kubeark involves a series of straightforward steps that allow users to set up and deploy functions efficiently. Below is a detailed guide on how to create a Function in Kubeark: 1. **Access the Functions Feature**: - Navigate to the 'Automation' menu in the Kubeark platform. - From there, select 'Functions' to access the functions management area. 2. **Initiate Function Creation**: - Click on the "Create Function" option. This action will bring up the interface for defining a new function. 3. **Configure Function Arguments**: - **General Details**: A new window will appear for you to input the necessary details for your function. Here, you'll need to provide: - `Name`: Enter a unique and descriptive name for your function. This name should identify the function’s purpose or its primary action. - `Description`: Provide a brief yet comprehensive description of what the function does. This should include its role and any significant details regarding its operation. - `Tags`: Add relevant tags to categorize and organize your function, facilitating easier management and identification within the platform. - In the same window, you will also need to configure the settings for the **Function Container Image**. This includes: - `Image`: Specify the container deployment image. This is the image that contains the code or application your function will run. - **Registry Authentication** arguments (if required): - `Registry`: Enter the name of the registry where your container image is stored. - `Auth Username`: Provide the authentication username for accessing the registry. - `Auth Password:` Enter the authentication password associated with the username. - Container Requests: - **CPU**: Define the amount of CPU resources the function should use. This should align with the function's processing requirements. - **Memory:**: Specify the memory allocation for the function. This ensures the function has sufficient memory to operate efficiently. 4. **Save and Deploy the Function**: - Once all the necessary information is inputted and configured, click on the “Save” button. - Your function will now be saved and deployed in Kubeark, ready to be integrated into your workflows or triggered as needed. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/RaoFNAZW6UIYZnJn67Fzc_image.png "Creating a Function in Kubeark") [title] Prerequisites [path] Getting Started/ Kubeark empowers companies to embrace digital innovation through comprehensive automation, resource optimization, and business efficiency capabilities. By eliminating barriers between tools, teams, and processes, Kubeark provides visibility, control, and collaboration and is reshaping the way enterprises handle digital transformation. Kubeark offers extreme scalability and fast time to market, remaining cloud agnostic. - [Licensing](docId\:cx2RUPgk-ZcUVCc3TrqPS) - [Network configuration & Firewall](docId\:El7fePCPQK1lovICYTbPj) - [Software Requirements](docId\:A4ygr3mSyOgaUFLEqSDZi) - [Hardware Requirements](docId\:MVYi8prmPe3iZgG_ZbipK) - [Initial Setup](docId\:ZAf7uT9RxEIJLXleRh7lv) [title] Product Guide [path] / [title] Licensing [path] Getting Started/Prerequisites/ The Kubeark licensing model is based on two main pillars: `templates` and `clusters`. These pillars determine the cost of the license, as well as the level of functionality and scalability that the platform provides. :::hint{type="info"} The license for the Kubeark Platform is generated by Kubeark and is currently available only as an offline license. ::: Templates refer to pre-built environments that are designed to run specific types of workloads or applications. These templates can include the necessary infrastructure, platform, and software components to run the workload or application, and are designed to make it easy for users to get started. The number of templates that a license includes is one of the key factors that determine the cost of the license. Clusters refer to the number of separate and independent environments that the license allows to be created. Each cluster is a complete, isolated environment that can include its own set of resources, such as virtual machines, storage, and network. The number of clusters that a license includes is another key factor that determines the cost of the license. The more clusters allowed by the license, the more workloads and applications that can be run simultaneously, which makes it more powerful and scalable. The Kubeark license model is designed to provide a flexible and cost-effective way to access the platform. It enables customers to pay only for the resources and functionality that they need, while also providing the ability to scale up as their requirements change. The license is based on the customer's needs and can be generated to include a specific number of templates and/or a specific number of clusters. **Templates** are pre-configured sets of settings and data that can be used to quickly create new clusters and get started with the platform. Clusters are the primary unit of organization in the Kubeark platform and allow users to manage and access their data, workflows, and reports. The license can be generated to include the specific number of templates and clusters that the customer needs, depending on their usage and requirements. For example, a customer who needs to manage a large amount of data and workflows may require a license that includes a larger number of templates and clusters, while a customer with more limited needs may require a license that includes a smaller number of templates and clusters. [title] Triggers [path] Automation Menu/ **Triggers** within the **Workspace** section empowers you to set precise conditions and actions, automating responses to various events or data changes. By defining trigger rules, you can ensure that your automation processes are not only efficient but also responsive to real-time events. This feature simplifies the execution of tasks based on specific triggers, reducing manual intervention and enhancing overall efficiency. Triggers in Kubeark are powerful components that initiate the execution of one or multiple workflows based on specific conditions. A trigger can be considered active when it is enabled and the output of its associated Expression evaluates to True. Once a trigger is activated by a designated source, such as an event or a predefined condition, it initiates the processing of workflows. Triggers serve as the catalyst for workflow execution, ensuring that the defined automation processes are triggered at the right time and in response to the relevant events or conditions. By enabling and configuring triggers, users can define the precise circumstances under which workflows should be started. The activation of a trigger results in the processing of workflows that are associated with it. This allows for the execution of a series of tasks or actions defined within the workflows, enabling automation and orchestration of complex processes. Triggers can start a single workflow or multiple workflows simultaneously, depending on the configuration and requirements set by the user. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/5mr3G13mfr9lhWLk_qENp_image.png) ## Menu navigation Within the main Triggers menu, you will find a couple of options to help you filter by workspace and configure your triggers accordingly. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/DIj4TTGDTFOYGyTCaaEV__image.png) 1. `Workspace filter`: in the right upper corner you will find a dropdown that allows you to select the desired workspace for further configuration 2. `Triggers` and `Sources`: on the left upper corner you will find two submenus allowing you to enter the individual setup for triggers and for sources. *** ### Quick recap: ::::VerticalSplit{layout="left"} :::VerticalSplitItem The `Automation` menu of the Kubeark platform interface offers a powerful set of tools and features designed to streamline and simplify various tasks within the platform. This contains three main sections: **Workspace**, **Forms** and **Functions** ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/kRHD38snrwOQy0YVo10tV_image.png) ::: :::VerticalSplitItem 1. **Workspace**: A useful menu that enables you to design, visualize, and execute complex automation sequences effortlessly by configuring Workflows, Triggers, Cron Jobs, the Vault and Logs. 2. **Forms: **The Forms section enables the creation and customization of digital forms, making it easy to collect structured data from users within the Kubeark platform. 3. **Functions: **Functions are code snippets or scripts that can be triggered to perform specific actions or tasks within Kubeark ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/NjZ2XEQl1HQjHo0d8109Q_image.png" signedSrc="https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/NjZ2XEQl1HQjHo0d8109Q_image.png" size="54" width="390" height="700" position="center" caption="We are here!" alt} ::: :::: *** ## How to setup triggers The `Triggers` submenu within `Workspace` allows you to set precise conditions and actions, automating responses to various events or data changes. By defining trigger rules, you can ensure that your automation processes are not only efficient but also responsive to real-time events. 1. Make sure you have selected the correct workspace from the upper right dropdown 2. Select the **Triggers** tab on the upper left corner 3. To create a new trigger, click on the "**Add Trigger**" button. A new window will appear, allowing you to configure the trigger's settings 4. A new window appears where you will need to configure the trigger arguments as follows: | Argument | Description | | ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Name` | Assign a unique and meaningful name to your trigger. This helps you easily identify and manage it within your workspace. | | `Description` | Provide a brief yet informative description of your trigger. This serves as a quick reference to understand the trigger's purpose and functionality | | `Owner` | Specify the owner of the trigger. This is essential for accountability and ensuring that the right team member is responsible for the trigger's management | | `Source` | Define the source of the trigger. This identifies where the trigger is initiated or triggered from, providing context for its actions
*\*Please refer to the Sources section* | | `Tags` | Add relevant tags to categorize and organize your triggers. Tags simplify the process of searching and managing triggers, especially in larger automation projects | | `Active` | Toggle the trigger's active status | | `Workflows` | Select the workflows associated with this trigger. | | `Expression` | Craft an expression that outlines the precise conditions triggering the automation. | ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/AlPz0-d5RO5_NrkaFrPnu_image.png) ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/Wzd0nlRv1QuFrtumtvVTH_image.png) ## Expression builder The Expression Builder in Kubeark is a specialized tool designed to facilitate the creation and management of events within the system. It allows users to define, customize, and automate responses to various system or user activities. The Expression Builder in Kubeark includes a range of Kubeark predefined events, meticulously crafted based on the most common use cases and our extensive experience, ensuring smooth and relevant experience for the users. Its primary purpose is to enable users to create specific "events" that act as triggers for certain actions within the Kubeark platform. An event in this context refers to a specific occurrence or a set of conditions being met within the platform. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/VlC0jUOWoJBcDld0EoNjj_image.png) Within the Expression Builder, select the "**Add Predefined Event" **option. This opens up a list of predefined Kubeark events. A complete list of predefined events that you can use can be found below: | Category | Events | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Workflow Events:** Include triggers for creation, update, deletion, publication, and rollback of workflows. | - Workflow created - Workflow updated - Workflow deleted - Workflow published - Workflow rollback
| | **Form Events**: Typically used for actions triggered by form submissions | * `Form submitted` | | **Deployment Events**: Cover a range of deployment-related triggers, including creation, enabling/disabling, deletion, and status updates.
Reference: [Deployments (Kubernetes)](docId:7WZfju1gVMXL7sbQckKoW) | - `Deployment created` - `Deployment disabled` - `Deployment enabled` - `Deployment hard deleted` - `Deployment soft deleted` - `Deployment status updated` - `Deployment updated` - `Deployment upgrade failed` - `Deployment upgrade succeeded` - `Deployment time extended` - `Deployment stopped` - `Deployment tags added` - `Deployment replicas updated` - `Deployment image updated` - `Deployment installation failed` - `Deployment installation succeeded` - `Deployment deleted`
| | **Template Events**: Relate to the creation, deletion, and other changes in templates.
Reference: [Templates (Kubernetes)](docId\:Eud4OZB9ivS8-u3wW7-fA) | * `Template created` * `Template deleted` * `Template updated`
| | **Cluster Events**: Include additions, updates, and deletions of clusters.
Reference: [Clusters](docId\:ICQ1CxzQv6obeZzz_YNVe) | - `Cluster added` - `Cluster hard deleted` - `Cluster updated` | | **K8s Events**: Encompass actions within Kubernetes, such as namespace deletion or resource updates.
Reference: [Kubernetes](docId\:DrumR3LkO8miPVxhhamwg) | * `Namespace deleted` * `Resource created` * `Resource deleted` * `Resource updated` | | **Infra Deployment Events**: Focus on infrastructure deployment actions like creation, updates, and provisioning.
Reference: [Deployments (Infrastructure)](docId\:rHodk9LX2IsI5RBpSHOtm) | - `Infra Deployment created` - `Infra Deployment updated` - `Infra Deployment provision plan created` - `Infra Deployment delete plan created` - `Infra Deployment deleted` | | **Infra Template Events**: Involve creation, updates, and deletion of infrastructure templates.
Reference: [Templates (Infrastructure)](docId\:aXq0Z6pmdsCGBURROuYWc) | * `Infra Template created` * `Infra Template updated` * `Infra Template deleted` | ## How to setup Sources A source, in the context of Kubeark, acts as an entry point for real-time data and events, enabling your automation processes to react swiftly to changes, updates, or notifications originating from a wide array of platforms and services. In Kubeark, the 'Sources' submenu under the Triggers page is a key component that allows users to configure various external services and platforms as sources for triggering events within the Kubeark environment. This feature enables the integration of a wide range of external systems and services, making it possible to create responsive and dynamic workflows that react to changes or events occurring outside the Kubeark platform. By configuring these sources, users can leverage external data and events to automate processes, enhance operational efficiency, and create a more interconnected system. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/3xYB38rmmIzCR8YkOR21p_image.png) - Go to the **Automation Menu > Workspace > Triggers **and select the** Sources **tab ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/j8OzVTlOgUHmvRuG_avwU_image.png) - Click on "**Add Source**" - Configure the Source arguments, as follows: | Argument | Description | | ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Name` | Assign a unique and meaningful name to your Source. This helps you easily identify and manage it within your workspace. | | `Description` | Provide a brief yet informative description of your Source. This serves as a quick reference to understand its purpose and functionality | | `Owner` | Specify the owner of the configured Source. This is essential for accountability and ensuring that the right team member is responsible for managing it | | `Tags` | Add relevant tags to categorize and organize your triggers. Tags simplify the process of searching and managing triggers, especially in larger automation projects | | `Active` | Toggle the trigger's active status | | `Source Type` | Select from a list of various external services
1) **AWS CloudWatch**: Integrate with AWS CloudWatch to receive alerts and notifications based on specific metrics or log monitoring, enabling triggers based on cloud resource performance and status. 2) **AWS SQS (Simple Queue Service)**: Connect with AWS SQS to trigger actions in Kubeark based on messages in the SQS queues, facilitating smooth handling of distributed messaging and event-driven processes. 3) **Azure Active Directory**: Utilize events from Azure Active Directory, such as user authentication or group changes, to initiate workflows, enhancing security and user management automation. 4) **Container Registry**: Configure triggers based on activities in your container registry, such as new image pushes or updates, to automate deployment workflows and maintain consistency in container management. 5) **GitHub**: Set up triggers based on GitHub events, like commits, pull requests, or releases, to automate code integration, testing, and deployment processes within your workflows. 6) **HELM**: Integrate with HELM chart events to trigger actions in Kubeark, ensuring seamless application deployment and management in Kubernetes environments. 7) **HTTP Poller**: Use HTTP Poller to regularly check web services or APIs and trigger events based on the response, allowing monitoring and reaction to external web services. 8) **NATS**: Connect with NATS messaging system to trigger events based on messages or topics, enabling real-time, distributed communication in your workflows. 9) **Apache Pulsar**: Integrate with Apache Pulsar to leverage its distributed pub-sub messaging for triggering real-time events, enhancing the responsiveness of your system. 10) **Azure Service Bus**: Utilize Azure Service Bus to create triggers based on messages in queues, topics, or subscriptions, facilitating complex integrations and event-driven architectures in cloud environments. | :::hint{type="info"} When selecting a source from the list in the 'Sources' submenu, be aware that each source will present a unique set of arguments tailored to its specific connection requirements. For instance, if you choose "AWS SQS" as your source, you will need to configure arguments pertinent to AWS integration. These may include AWS credentials, Access Key ID, Secret Access Key, Queue Name, and AWS Region, among others. It's essential to carefully fill in these details to ensure a seamless and secure connection between Kubeark and the selected external source. ::: [title] Templates (Infrastructure) [path] Environments Menu/Kubeark Infrastructure/ ## Overview **Infrastructure Templates are Terraform-centric. **Beyond the realm of Kubernetes, the Infrastructure templates expand deep into the broader architecture of infrastructure management and provisioning.  These templates, specifically tailored for Terraform, act as scripts or blueprints for defining and provisioning your infrastructure resources. They cater to tasks like provisioning virtual machines, setting up networks, orchestrating storage solutions, and more. With Terraform's declarative language and Infrastructure-as-Code (IaC) capabilities, these templates ensure that infrastructure is consistently and reliably provisioned, managed, and scaled. ## How to create an infrastructure template? **Step1 - Access the Templates menu:** Start by navigating to the Environments section, under Infrastructure. **Step2 - Initiate template creation**: Once inside the Templates menu, locate and click on the "create template" button. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/3o1fY0SBg9ciPUeK3lFDn_image.png) **Step3 - Template Creation Page:** You will now be taken to the template creation page, a dedicated space where you can specify various details for your new infrastructure template. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/Dp8p4LD0ZwOXWeCd6GRK0_image.png) | **Argument** | **Description** | | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Name` | Provide a descriptive and unique name for your template | | `Description` | Offer a brief summary or explanation about the template's purpose or characteristics | | `Owner` | Specify the owner responsible entity for this template | | `Configuration archive` | This option allows you to load a custom configuration. Click on the provided space or button to upload your custom configuration. Ensure that the configuration file is in the acceptable formats—either a gzip or tar archive. | | `Cofiguration text` | Allows for manual input of arguments | | `Tags` | Add a custom tag to reference your template | | `Environment action` | This argument allows adding business logic for the environments lifecycle, and can be defined through: -> Terminate - This is when the environment is terminated when the default timeand grace time reaches 0 seconds-> Manual - Manual trigger | | `Default time` | The default expiration time when the action is triggered | | `Grace time ` | The grace time to wait after the default time for the environment action to be triggered. | | `Input variables` | Variables are used to generate random data. You can use them in the values field of the extra arguments section. You can combine them with other values.For example, \{\{set\_string}}-test the result will be a random string followed by the word test. You can also use them in a payload from a value of extra arguments, combined with other values or predefined variables.The following predefined variable categories are available:-> Infra-> User-> FunctionAdditional parameters can also be added, the platform supporting various formats such as *string, numeric, JSON, Code, List or Boolean* | ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/lwXwCFb7GhHr15A-Li9CH_infra-templ-3.png "Configuration archive") **Step 4 -** **Finalize Creation**: After filling out all the relevant information, review your entries for accuracy. Once satisfied, click on the `Create` button to finalize the creation of your infrastructure template. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/f8aVVmVrIc_GfpZjwRvEO_image.png) [title] Cluster Management [path] / [title] Product Lifecycle [path] Lifecycle/ Welcome to the Kubeark Product Lifecycle page. Kubeark is a cutting-edge platform that provides innovative solutions for deploying and managing Kubernetes applications at scale. As with any software product, Kubeark has a defined lifecycle that includes different stages of support and maintenance. This page outlines the key milestones in the Kubeark product lifecycle, including release dates, support timelines, and end-of-life dates. By understanding the different stages of the product lifecycle, users and administrators can plan for upgrades and migrations, as well as taking advantage of the latest features and enhancements. | **Product** | **Version** | **Support model** | **Release date** | **End of Full Support** | **End of Limited Support** | | ---------------- | ----------- | ----------------- | ---------------- | ----------------------- | -------------------------- | | Kubeark Platform | 3.0 | FS\* | Apr 28, 2023 | Apr 27, 2025 | n/a | | | 4.0 | FS | Aug 1st, 2023 | Jul 31, 2025 | n/a | | | 5.0 | FS | Dec 20th, 2023 | Nov 20th, 2025 | n/a | | | 6.0 | FS | April 20th, 2024 | March 20th, 2025 | n/a | :::hint{type="info"} **FS **- Full Support **LS **- Limited Support will include only security fixes ::: [title] Local Vault [path] Automation Menu/ In the Kubeark platform, the Vault represents a highly secure and efficient solution for managing and storing a wide array of variables crucial to your operations. Essentially, it acts as a secure central repository for various configuration values such as database credentials, API keys, and environment-specific settings. In the Kubeark platform, the **Vault** is conceptualized and accessible from two distinct perspectives, catering to different scopes and levels of variable management. Understanding these two facets of the Vault is key for effective configuration and usage within the platform. 1. **Workspace Vault (Local Vault): **This version of the Vault is designed to be unique to each workspace. It allows for the creation and management of variables that are specifically tailored and confined to a single workspace. 2. **Global Vault (Central Vault): **This Vault is conceptualized as a platform-wide repository. The variables stored here are generally available and applicable across the entire Kubeark platform. :::hint{type="warning"} The Global Administrator in the Kubeark platform, will have the ability to view all variables stored within the Global Vault as well as the Workspace Vaults (Local Vaults) ::: ## The Workspace Vault The Vault is designed to be allocated to specific workspaces, allowing for a tailored approach to variable management. Customization of the Vault for each workspace ensures that variables are not only stored securely but also segregated according to the needs and context of each workspace. This segregation enhances security by ensuring that sensitive information is accessible only within its relevant environment, thereby reducing the risk of unauthorized access or cross-environmental data breaches. Users can define variables (like variable name, scope, scope ID, description, value, and the 'Is secret?' flag) that are relevant to the processes and workflows within that particular workspace. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/3dCskL1xpWMIS579e4vCw_image.png) ### Step-by-step guide for defining new variables in the Workspace Vault Creating a variable in the Workspace Vault of Kubeark is a straightforward process. Here is a step-by-step guide to help you through it: 1. **Initiate Variable Creation**: - Start by navigating to the Workspace **Vault** within your selected workspace. - Click on “Create New Variable.” This action opens the interface for defining a new variable. 2. **Configure Variable Arguments**: - **Variable Name** : Enter a unique and descriptive name for the variable. This name should be indicative of its purpose or the value it holds. - **Scope** : Since you are creating this variable within the Workspace Vault, set the scope to 'workspace'. This ensures that the variable is recognized as belonging to and usable within this specific workspace. - **Scope ID** : Enter a numeric value that uniquely identifies this variable within the workspace. The Scope ID helps in distinguishing this variable from others in the same scope. - **Description** : Provide a clear and concise description of the variable. This should include its purpose and any relevant details that will aid in its identification and use. - **Value** : Input the value that the variable will hold. This could be a string, number, or any data format that the Vault supports. - **Is Secret Flag** : Determine whether this variable contains sensitive information. If it does, toggle the 'Is Secret' flag to ‘Yes’. This ensures that the variable is treated with an additional layer of security, masking its value from general visibility and ensuring secure handling. 3. **Save the Variable**: - After inputting all the necessary details and configurations, click on the “Save” button to store the variable in the Workspace Vault. - Once saved, the variable is now securely stored in the Vault and is accessible for use within the designated workspace according to its defined scope and settings. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/MF7Lh2ezVL68g4RT26l3M_image.png) ## The Global Vault The (Global)`Vault` can be found under the `Settings Management` section of the main features menu. [title] Template Versioning [path] How to's/ Kubeark Templates enable you to customize everything needed to fit your pipeline needs. Define it once and use it multiple times! Templates in Kubeark are pre-built configurations that include all the resources necessary to run a specific workload or application. They are designed to save time and reduce errors when scaling, by providing all the necessary infrastructure, platform, and software components. They are easy for users to implement and get started with. Kubeark supports template versioning - The templates within the Kubeark platform have the capability to have an unrestricted number of versions, however, the number of active versions will depend on the type of license purchased. :::hint{type="info"} Multiple template versions can be created, however please consider that the number of active versions allowed depends on the type of license allocated to the respective user. ::: Going further, let’s see how to create and manage template versions. ### Step 1: Select your desired template from the Template Group. :::hint{type="info"} We have previously learned how to create and manage a Template Group - please refer [Template Groups](docId\:K_kBPnulstc8byJkKHTtX) ::: - To begin, go to the `Template Management` menu on the left-hand side of your platform interface and select `Groups`. ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/pFz_Ij-fh-z7wjtjsm1L9_tmp-ver-1.png" signedSrc="https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/pFz_Ij-fh-z7wjtjsm1L9_tmp-ver-1.png" size="58" width="512" height="348" position="center" caption} - Select your group from the list of existing groups and here you will see the Templates list. - Select your desired template from the list of templates ### Step 2: Create template version - On the upper right side of the screen, an option named `Create Version` will be visible. Here you will also find a list of all available versions linked to this main template, if any have been previously created. ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/erbqnuBiDDoSoZDg5icX1_tmp-ver-2.png" signedSrc="https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/erbqnuBiDDoSoZDg5icX1_tmp-ver-2.png" size="40" width="330" height="680" position="center" caption} - Upon selecting the `Create version` button, a new window will display, which allows you to update the required arguments for your new template version ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/hjrhIUZ2s-iGsLjjwoSjZ_tmp-ver-3.png) :::hint{type="info"} Detailed instructions on the template creation, along with the explanation of each argument and extra argument can be found here [Templates (Kubernetes)](docId\:Eud4OZB9ivS8-u3wW7-fA) ::: - Two important sections to be considered when creating a template version are the `Chart information` and the `Additional parameters` ::::VerticalSplit{layout="left"} :::VerticalSplitItem **The Chart information section:** Here you will be able to add the chart information, repository name, repository URL and Path The **Additional parameters** section ::: :::VerticalSplitItem ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/zYYmcSkYAiw1pkFZ8ecdB_tmp-ver-4.png) ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/KSLpMMZSwTLEtx5xoPTpZ_tmp-ver-5.png) ::: :::: - Once you have added all the arguments, click on `Save` [title] Core Concepts [path] Automation Menu/ When talking about Automation int the Kubeark context, it is important to understand the core concepts and terminology around the platform interface. ::::VerticalSplit{layout="left"} :::VerticalSplitItem ****[Workspace](docId\:rBBEpzII6ufbiJeDv5xl1) ::: :::VerticalSplitItem - An organizational construct that groups together related resources and settings for effective management and collaboration. - It serves as a container within which users can manage a variety of entities such as Kubernetes clusters, templates, and deployments, as well as infrastructure components. - Workspaces allow users to segment and organize their projects or resources based on teams, projects, or any logical grouping, providing a structured approach to resource management. ::: :::: ::::VerticalSplit{layout="left"} :::VerticalSplitItem [Workflows](docId\:K5wX3wwWutvgkjpDRPV_G) ::: :::VerticalSplitItem - A workflow in Kubeark is an automated sequence of tasks or operations designed to accomplish a specific objective or process. - It represents a series of actions, often linked by logic or conditions, that are executed to manage and orchestrate tasks within the platform. - Workflows in Kubeark typically involve automating interactions between different components like Kubernetes resources, infrastructure elements, and other integrated services. ::: :::: ::::VerticalSplit{layout="left"} :::VerticalSplitItem **Nodes** ::: :::VerticalSplitItem - Fundamental building blocks of a workflow. - Represent specific actions or operations like data transformations, system integrations, and conditional branching. - Organized into various types such as Control Nodes, Action Nodes, Task Nodes, and Kubeark Nodes, each serving a distinct purpose within the workflow. ::: :::: ::::VerticalSplit{layout="left"} :::VerticalSplitItem **Triggers** ::: :::VerticalSplitItem - Mechanisms that initiate the execution of a workflow. - Can be set to respond to internal events within Kubeark as well as from external sources, such as changes in resource status or specific system conditions. - Enable workflows to run automatically, facilitating real-time responses to events. ::: :::: ::::VerticalSplit{layout="left"} :::VerticalSplitItem **Webhooks** ::: :::VerticalSplitItem - Used to trigger workflows based on external events. - Allow Kubeark workflows to integrate with external systems and services. - When a specific event occurs in an external service, the webhook sends data to Kubeark, triggering the associated workflow. ::: :::: ::::VerticalSplit{layout="left"} :::VerticalSplitItem **Forms** ::: :::VerticalSplitItem - User interfaces within the main Workspace container for capturing input. Forms can trigger subsequent Workflows. - Allow for manual data entry or selections that can determine the course or configuration of a workflow. - Useful for workflows that require user decisions or inputs at certain stages. ::: :::: ::::VerticalSplit{layout="left"} :::VerticalSplitItem **Cron Jobs** ::: :::VerticalSplitItem - Enable scheduling of workflows to run at specified times or intervals. - Useful for regular tasks like maintenance, backups, or periodic updates. - Help automate repetitive tasks, ensuring they occur without manual intervention. - Cron Jobs operate at Workspace level and can be associated with multiple subsequent Workflows ::: :::: [title] How to's [path] / [title] Password stage [path] Product Guide/Organization Administration/Untitled/Untitled/ The Password prompt is a standard way of verifying the identity of the `pending_user`. This stage also enables the choice of the authentication source for the user. ### Passwordless authentication There are two distinct methods to configure passwordless authentication. One method is to directly authenticate users with their authenticator, which is only supported for WebAuthn devices. ::::WorkflowBlock :::WorkflowBlockItem **Direct authentication using authenticator:** Passwordless authentication currently only supports WebAuthn devices, like security keys and biometrics. For an alternate passwordless setup, see Password stage, which supports other types. To configure passwordless authentication, create a new Flow with the delegation set to *Authentication*. ::: :::WorkflowBlockItem **Dynamically skip the password stage** ::: :::: As first stage, add an *Authentication validation* stage, with the WebAuthn device class allowed. After this stage you can bind any additional verification stages. As final stage, bind a *User login* stage. Users can either access this flow directly via it's URL, or you can modify any Identification stage to add a direct link to this flow. The second method involves dynamically skipping the password stage based on the user's device. The documentation for this method can be found here. [title] Deleting a Cluster [path] How to's/ Deleting a Kubernetes cluster is a common task that may be necessary when the cluster is no longer needed or has become outdated. Before proceeding with the deletion process, it's important to ensure that any important data or resources within the cluster have been properly backed up or transferred to a new location. In this tutorial, you will be guided through a systematic process for deleting a cluster, utilizing the Kubeark platform. Kubeark is an powerful tool that simplifies cluster management, making it an ideal solution in the DevOps landscape. With the Kubeark platform, deleting a cluster is a straightforward process that can be completed in just a few steps. - Go to the Kubeark platform and select `Cluster Management` from the menu on the left-hand side of the screen. Then, click on `Clusters` to view a list of all available clusters. - ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/M9DvIEgrhQJlc7v4yOlCm_clst-1.jpeg" signedSrc size="66" width="261" height="129" position="center" caption} - Kubeark offers three possible ways to disable a cluster: you can disable, soft delete or hard delete a cluster. You may choose the option that best fits your needs as follows. ### Option 1: Disable To disable a cluster, simply locate the **Active** column on the clusters page described above and change its status from `Active` to `Disabled`. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/ra8S9mvhDjyTyI2lgbYLh_clst-2.jpeg) :::hint{type="info"} By disabling a cluster, you will prevent the creation of new deployments on this cluster. Existing configurations remain unchanged while the associated deployments are disabled. ::: ### Option 2: Soft Delete To perform a soft delete, click on the `Delete cluster` button (trash bin icon), which can be found in the right side of the screen for each individual cluster line. This button opens a pop-up window with three options: "No", "Delete", and "Hard Delete". ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/i_3AW_96jqEq9PjmT2iiQ_clst-3.jpeg) ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/a4KipWkfguR1k5Qw--fjv_clst-4.png) Clicking on `Delete` will erase the configuration for the respective cluster, without removing it from the list. This is what we call a “soft delete”. :::hint{type="warning"} This option will delete the configuration and disable the associated resources. ::: ### Option 3: Hard Delete Select the `Delete cluster` button (trash can icon), which can be found in the right side of the screen for each individual cluster line. This button opens a pop-up window with three options: "No", "Delete", and "Hard Delete". To permanently delete the cluster and all its configuration files, choose the `Hard Delete` button. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/zaN0vxd1vmNFYndctztjr_clst-5.png) :::hint{type="warning"} This will remove the cluster from the list of available clusters, and all associated deployments will be also removed. Be advised that this action cannot be undone, and all data and configurations associated with the cluster will be permanently deleted ::: ### Summary Below you will find a summary of all available options and their respective dependencies that should be considered when disabling a cluster. The table below outlines the impact of each selected option on the cluster configuration, deployments, and resources. It is important to carefully evaluate the specific requirements of your cluster before deciding on the most appropriate option for disabling it. | **Selected option** | **Cluster configuration** | **Deployment** | **Resources** | | ------------------- | ------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------ | | Disable | No impact | Deployment status is also moved to DisabledThis can easily be reversed once the cluster status is set back to Active and the deployment will be up and running. | The resources are **up and running** | | (Soft) Delete | Erases the cluster configurationCluster still shows on the list of available clusters | Deployment is moved in Soft\_Delete status.Once the cluster configuration is updated, the deployment will be up and running again | The resources are **Disabled** | | Hard Delete | Permanently deletes the cluster from the list of clusters | All deployments associated with the respective cluster are deleted | The resources are **Deleted** | [title] Captcha stage [path] Product Guide/Organization Administration/Untitled/Untitled/ ## Google Capthca This stage incorporates a validation mechanism utilizing [Google's ReCaptcha](https://www.google.com/recaptcha/intro/v3.html) or other comparable services. The present supported versions are ReCaptcha, hCaptcha, and Turnstile. This stage has two required fields: Public key and private key. These can both be acquired at [https://www.google.com/recaptcha/admin](https://www.google.com/recaptcha/admin). ## hCaptcha Documentation available here [https://docs.hcaptcha.com/switch/](https://docs.hcaptcha.com/switch/) ## Turnstile Documentation available here [https://developers.cloudflare.com/turnstile/get-started/migrating-from-recaptcha](https://developers.cloudflare.com/turnstile/get-started/migrating-from-recaptcha) [title] Actions [path] Automation Menu/Workflows/About Nodes/ The **Actions** category contains default nodes, designed to facilitate common automation activities and implement business logic directly out of the box. These predefined nodes cover a wide array of functionalities, making them immediately useful for many standard automation tasks. To simplify the use of Actions, we have categorized them into three distinct groups: - **Default Actions**, which are predefined actions constructed upon widely-used industry tools and programming languages (e.g. Bash, Golang, Dotnet etc.) - **Kubeark Actions**, which are predefined actions developed by Kubeark, tailored specifically for Kubernetes and infrastructure management (e.g. Add Kubeark Cluster, Get Deployment etc.) - **Custom Actions**, which are user-defined snippets that can be personalized and preserved to meet individual requirements. | **Category** | **Action** | **Description** | | ------------------- | ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | | **Default Actions** | `Bash` | Executes Bash script commands for various automation and scripting tasks within the workflow. | | | `Deno` | Executes Deno scripts, leveraging Deno's runtime for JavaScript and TypeScript. | | | `Dotnet` | allows you to run C# (or other .NET-compatible language) scripts or programs within the context of an automation or data-processing workflow | | | `Golang` | Runs Golang scripts or programs, utilizing Go's powerful programming capabilities. | | | `HTTPRequest` | Sends HTTP requests to external services or endpoints, facilitating API interactions. | | | `Kubectl` | Executes Kubectl commands for direct manipulation and management of Kubernetes resources. | | | `Playwright` | Automates web browser interactions for testing web applications using Playwright scripts. | | | `Python` | Executes Python scripts, tapping into Python's extensive programming capabilities. | | | `SSH` | Performs operations on remote servers or devices via Secure Shell (SSH) commands | | **Kubeark Actions** | `Add Kubeark Cluster` | Integrates a new Kubernetes cluster into the Kubeark platform for management and deployment. | | | `Create Deployment` | Initiates a new application deployment within a Kubernetes environment. | | | `Create Infra Deployment` | Starts a new infrastructure deployment, setting up the necessary infrastructure components. | | | `Create Template` | Generates a new template for defining and standardizing deployment configurations. | | | `Delete Deployment` | Removes an existing application deployment from Kubernetes. | | | `Delete Infra Deployment` | Deletes an existing infrastructure deployment, cleaning up the allocated resources. | | | `Delete Kubeark Cluster` | Removes a previously integrated Kubernetes cluster from the Kubeark environment. | | | `Get Deployment` | Retrieves details about a specific application deployment in Kubernetes. | | | `Get Infra Deployment` | Fetches information on a specific infrastructure deployment within the platform. | | | `List Infra Deployments` | Lists all existing infrastructure deployments within the platform, providing an overview. | | | `Update Deployment` | Updates settings or configurations of an existing application deployment in Kubernetes. | | | `Update Template` | Modifies an existing template to adjust deployment configurations or parameters. | | **Custom Actions** | *\*User-defined* | | [title] Default Actions [path] Automation Menu/Workflows/About Nodes/Actions/ This category contains default nodes, designed to facilitate common automation activities and implement business logic directly out of the box. These predefined nodes cover a wide array of functionalities, making them immediately useful for many standard automation tasks. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/JtDDU273H1ek1fpX9GIAQ_image.png) ## Bash The Bash Node in Kubeark is a type of execution node designed for running Bash scripts or commands within a workflow. It allows users to incorporate shell scripting into their data processing or automation tasks, facilitating operations like file manipulation, system administration, and execution of software or commands available in a Bash environment. By leveraging the Bash Node, users can execute custom scripts or commands on a Linux-based executor, enabling a wide range of operations that can be scripted in Bash, such as: - Data processing tasks, like file sorting, filtering, and aggregation. - System operations, including file system management, process control, and environment configuration. - Interfacing with other software tools or services that can be controlled via command-line interfaces. To use the Bash Node, you would typically specify the script or commands to be executed, along with any necessary input parameters or environment variables. Here is a detailed breakdown of the configuration options: - **Name**: The identifier for this particular Bash Node in your workflow. - **Condition**: This field is where you specify the condition under which this node will be executed. If you set a condition, the node will run its script only when that condition evaluates to true. - **On Error**: Determines what happens if an error occurs during the execution of the Bash script. Options might include stopping the workflow, retrying the node, skipping it, or executing a compensatory action. - **Vault**: The vault reference. Please refer [Local Vault](docId:6UOO8pp2iYgibUmgRCNwi) - **Input**: - **Environment Variables**: Here, you can declare environment variables that the Bash script will use. These could be paths, configuration settings, or any other data that shouldn't be hardcoded into the script. - **Script**: The main field where you input the actual Bash commands or script to be executed. This script can perform a wide array of tasks, from file manipulation to running applications and services. When this node is activated, the Bash script provided will be run in a shell environment. The ability to execute Bash commands adds powerful capabilities to your workflow, allowing for complex operations that take full advantage of the host system's features and installed tools. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/9BHSvWzKyx8bnGuS32pxy_image.png) ## Deno Deno is a JavaScript/TypeScript runtime with secure defaults and great developer experience. It's similar to Node.js but includes some key differences, like security defaults that restrict file, network, and environment access unless explicitly enabled. Here is a description of the Deno arguments required for configuring this node: - **Name**: This is where you name your Deno node for identification within your workflow. - **Condition**: Conditions determine when this node will execute within your workflow. If a condition is set, the Deno script will only run when the condition is met. - **On Error**: This defines the behavior of the workflow if the Deno node encounters an error during execution. The action could be to stop the workflow, skip the error, retry, and so forth. - **Vault**: This would be used to select secure storage for sensitive data like API keys or passwords. Scopes can be defined to limit access. Please refer to [Local Vault](docId:6UOO8pp2iYgibUmgRCNwi) - **Input**: Here, you would provide any input data the Deno script needs. Inputs are typically key-value pairs that the script can use. - **Environment Variables**: Similar to inputs but specifically for environment variables that your Deno script may require to run, such as configuration settings that should not be hard-coded into the script. - **Packages**: While Deno doesn't use npm, and thus does not have a package.json file like Node.js, this section might be used to specify third-party modules or dependencies that your script requires. In Deno, modules are imported directly from URLs. To use this node, you would need to provide the necessary script, configure any inputs or environment variables your script requires, and set up error handling according to your workflow's needs. The configured node can then execute TypeScript or JavaScript within the secure Deno environment as part of a larger automated process. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/KuvFFaXNwLxWPlxQjBNsy_image.png) ## Dotnet A **Dotnet** (.NET) node allows you to run C# (or other .NET-compatible language) scripts or programs within the context of an automation or data-processing workflow. Here's a breakdown of the configuration options available: - **Name**: This is the identifier for the .NET node within the workflow. It helps you distinguish between different nodes when managing or reviewing workflows. - **Condition**: This optional field allows you to specify a condition under which the .NET node will be executed. If a condition is given, the node will only run its .NET script when that condition is true. - **On Error:** Here, you can define what should happen if the .NET node encounters an error during its execution. Options might include stopping the workflow, skipping the node, retrying, etc. - **Vault:** If your .NET script needs to use sensitive data, such as passwords or API keys, you would use this section to select the appropriate secure storage - see [Local Vault](docId:6UOO8pp2iYgibUmgRCNwi) - **Input**: In this section, you would specify any input data that the .NET script requires. Inputs are generally in the form of key-value pairs that the script can consume. - **Environment Variables:** These are key-value pairs that the .NET node's environment will recognize. They are similar to inputs but are used specifically for environmental configuration rather than script inputs. - **NuGet Packages:** Since .NET applications often rely on external libraries, this section allows you to specify any NuGet packages that your script depends on. NuGet is the package manager for .NET, providing a collection of libraries and tools for .NET developers. When you use this node, you would write a .NET script or program and input it into the system, specify any dependencies it has via NuGet, and configure any inputs or environment variables required. This node then processes the .NET code within the context of the larger workflow, which can involve multiple other nodes, potentially written in different languages or performing different tasks. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/OVMf6Ee5jGkV3pW0IiFqF_image.png) ## Golang This node is designed to run code written in the Go programming language, often referred to as Golang. Here’s a breakdown of the configuration options shown: - **Name**: This is where you give your Golang node a unique identifier for reference within your workflow. - **Condition**: If specified, this determines the conditions under which the Golang node will execute. You can configure this to run the node only when certain criteria are met within your workflow. - **On Error**: This configuration dictates the course of action if the Golang node encounters an error during its execution. Options might include actions like stopping the workflow, skipping the node, retrying the operation, etc. - **Vault**: use this section to select the appropriate secure storage - see [Local Vault](docId:6UOO8pp2iYgibUmgRCNwi) - **Input**: Here you would input any data that the Golang script requires to run, such as parameters for functions within the Go code. - **Environment Variables**: These are the environmental parameters that your Go code will use during execution. They are system-level information that can affect how your script runs. - **Modules**: Since Go uses modules to manage dependencies, this section would be where you specify external packages or modules that your Go code depends on. In practice, after setting the name and, if necessary, the condition for the execution, you would provide your Go code, ensure that all necessary modules and environment variables are specified, and set your on-error action. This Golang node can then be used as part of your workflow to automate tasks using Go, integrating with other nodes and services as required. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/io7RWIfaJ3z-mcZk07Kmx_image.png) ## HTTPRequest This type of node is designed to perform HTTP requests to communicate with web services. Here is the breakdown of the configuration fields: - **Name**: You assign a unique identifier to the node, in this case, it's `node_d6d57f0e`, which helps you identify it within your workflow. - **Condition**: This optional field allows you to define a condition under which the HTTPRequest node should be triggered. If set, the node will only execute the HTTP request when the condition evaluates to true. - **On Error**: Here you decide what action should be taken if an error occurs during the HTTP request. Options might include stopping the workflow, retrying the request, or proceeding with the next steps without taking any action. - **Vault**: use this section to select the appropriate secure storage - see [Local Vault](docId:6UOO8pp2iYgibUmgRCNwi) - **Input**: Under this section, you configure the details of the HTTP request. - **Method**: This is where you specify the HTTP method to use for the request, such as GET, POST, PUT, DELETE, etc. In your screenshot, GET is selected. - **URL**: You enter the URL to which the HTTP request will be sent. - **Authentication**: If the endpoint requires authentication, you select the type here. In your screenshot, Basic authentication is selected, which requires a username and password. Username: You provide the username required for authentication. Password: You provide the password corresponding to the username. - **Headers**: HTTP headers can be specified here to include additional information with the request, such as 'Content-Type' or 'Authorization' information. - **Body**: If the request method is one that allows a body, such as POST or PUT, you can provide the data to be sent with the request here. This field isn’t visible in your screenshot but would typically be included for methods that support a request body. Once configured, the HTTPRequest node will perform the specified HTTP request when triggered within the workflow. The node can handle the response, pass data to subsequent nodes, and integrate with different parts of the system or external services as part of an automated process. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/dgoUwNqSSfIHY6LqGMwcY_image.png) ## Kubectl **kubectl** is a command-line tool that allows you to run commands against Kubernetes clusters to deploy applications, inspect and manage cluster resources, and view logs. Here's what each part of the node configuration is for: **Name**: This is the identifier for the node within your workflow. Here, it is set to node\_edd3d087. **Condition**: This is where you can define conditions that must be met for the kubectl node to execute. It acts as a form of flow control, executing the kubectl command only when specific criteria are satisfied. **On Error**: This setting dictates what should happen if an error occurs during the execution of the kubectl command. You can typically choose to stop the workflow, ignore the error, or retry the command. **Vault**: The vault is used for securely storing and accessing secrets, like passwords or API tokens. This could be necessary if your `kubectl` command interacts with a Kubernetes cluster that requires authentication. Please refer [Local Vault](docId:6UOO8pp2iYgibUmgRCNwi) **Input**: **Cluster Id**: This refers to an identifier for a Kubernetes cluster within the system. The `kubectl` commands will be executed against the cluster with this ID. **Api Token**: This is the authentication token that `kubectl` will use to authenticate against the Kubernetes cluster API. **Args**: Here, you would specify additional arguments or parameters to pass to the `kubectl` command. This field might include the specific kubectl commands and options you want to run. By configuring and running this node, you can automate Kubernetes operations as part of a larger workflow, for instance, deploying applications, managing resources, or gathering information from your Kubernetes cluster. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/bOzy8ngE0EVVMzYKi5Kcv_image.png) ## Playwright The Playwright node configuration screens you've provided are for setting up a node that uses Playwright within a workflow. Playwright is a Node library that enables developers to automate browser tasks such as testing web applications across various browsers. Let's go through the configuration options: 1. **Name**: This field is for the unique identifier of the Playwright node in your workflow, here named `node_807b0760`. 2. **Condition**: This optional field allows you to define conditions for the node's execution. If specified, the node will execute its actions only when the set condition(s) is true. 3. **On Error**: This determines what should happen if an error occurs during the Playwright node's execution. You might choose to stop the process, ignore the error, retry the action, etc. 4. **Vault**: use this section to select the appropriate secure storage - see [Local Vault](docId:6UOO8pp2iYgibUmgRCNwi) 5. **Input**: This section contains various configuration options: - **Config**: This sub-section typically contains settings for how Playwright should operate. - **Device**: Specifies the device emulation settings for the browser, e.g., 'Desktop Chrome'. - **Retries**: The number of times the node should retry the action in case of failure. - **Timeout**: Sets the maximum time to wait for the action to complete. - **Storage State**: Contains settings related to browser state like cookies and local storage. - **Cookies**: You might be able to specify particular cookie data here. - **Origins**: This could refer to the origin URLs for which the storage state (like cookies, local storage) applies. - **Storage State Path**: The path to the file with saved storage state that Playwright can use to initialize the browser context. 6. **Environment Variables**: Here you can set up environment variables that your Playwright scripts may require. 7. **Setups**: Specify custom setup scripts or configurations that need to be run before the main Playwright actions. 8. **Spaces**: A workspace or a specific area within the workflow platform where this Playwright node is applicable. The Playwright node allows you to automate browser actions as part of your workflows. You could use it for tasks like scraping web data, automating form submissions, or performing end-to-end tests on web applications. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/ESAkkhW-Vi2GcEmHLKH1T_image.png) ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/B1il2-LY_Q9xFmQndtUln_image.png) ## Python This node is designed to execute Python code as part of an automated sequence or data processing pipeline. Here’s a rundown of the configuration options shown: 1. **Name**: This is the unique identifier for the node in your workflow, which you can use to reference the node. 2. **Condition**: An optional setting where you can specify conditions that must be met for the node to execute. If a condition is provided, the node will only run its Python script when that condition is true. 3. **On Error**: Here, you define what should happen if the node encounters an error while executing the Python code. Options typically include stopping the workflow, skipping the node, or attempting to retry. 4. **Vault**: use this section to select the appropriate secure storage - see [Local Vault](docId:6UOO8pp2iYgibUmgRCNwi) 5. **Input**: Under this section, you configure the inputs that the Python script needs. - **Environment Variables**: These are variables that the Python environment will recognize and can affect script execution. You can add environment-specific variables that your script needs here. - **Packages**: If your Python script depends on third-party packages, you can list them here. This ensures that the necessary packages are available to the Python environment when the script runs. - **Script**: This is the most important part. It's where you input the actual Python code to be executed. This script can do anything that Python is capable of, given the node's permissions and available libraries, such as data manipulation, calling APIs, processing files, and more. When this node is executed within a workflow, it will run the specified Python script with the given environment variables and packages. This allows you to automate tasks using Python's powerful capabilities directly within your workflow. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/h2USgrasfwcs9cINu3tpT_image.png) ## SSH This node is designed to execute commands on a remote server through an SSH protocol, which provides a secure channel over an unsecured network. Here’s how you would use the fields in this configuration: 1. **Name**: Assign a unique identifier to this SSH node in your workflow, in this case, `node_ed726d50`. 2. **Condition**: Define a condition that determines when this node should be executed. If set, the node will only perform its action when the specified condition evaluates to true. 3. **On Error**: Decide the behavior of the workflow if there's an error during the SSH command execution. Options usually include stopping the workflow, retrying the command, or continuing with subsequent actions. 4. **Vault**: If the SSH login credentials or private keys are stored in a secure vault, you can specify which vault to access. Use this section to select the appropriate secure storage - see [Local Vault](docId:6UOO8pp2iYgibUmgRCNwi) 5. **Input**: Provide the necessary information to make an SSH connection: - **Username**: The SSH username for the remote server. - **Address**: The address of the remote server you want to connect to, typically an IP address or a domain name. - **Password**: The password associated with the SSH username. It's one way to authenticate the SSH session. - **Private Key**: An alternative to using a password, you can authenticate via a private key if the remote server supports key-based authentication. - **Script**: The actual shell commands or a script that you want to execute on the remote server. It's entered in the large text field. When triggered, the SSH node will establish a secure connection to the specified remote server using the provided credentials. Once connected, it will execute the given commands or script. This can be useful for automating deployment tasks, system administration, or any situation where remote server control is needed within a workflow. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/MAp-Vn9epeFTwZCnuZfeH_image.png) [title] About Nodes [path] Automation Menu/Workflows/ Workflows are designed with **nodes**, where each node represents a distinct action or function essential for automating specific tasks. **Nodes** in the context of Kubeark workflows are core components that represent distinct actions or operations within a workflow. These fundamental building blocks enable users to tailor their automation processes precisely. Each node encapsulates specific logic and functionality necessary for executing a particular task. They vary widely in their capabilities, from performing data transformations to system integrations, conditional branching, or even facilitating manual approvals. Effectively, nodes are the building blocks of a workflow, pieced together to create a comprehensive, automated process. Once familiarized with the concept of nodes as *the fundamental building blocks* within a workflow, we can explore the various top-level nodes available in the system. These top-level nodes serve as primary categories, each encapsulating a unique function or capability that you can utilize in constructing your workflows. From 'Actions' that serve as the doers of the workflow, performing a wide range of tasks, to 'Approve' nodes that pause the workflow for human input, each node is designed to streamline and automate processes effectively. Other top-level nodes include 'Workflow' for incorporating existing workflows, 'Define Variables' for setting up reusable elements, and control structures such as 'For Loop', 'While Loop', and 'Branch' that dictate the flow of execution based on logic and conditions. Additionally, utility nodes like 'Sleep' and 'Terminate' provide you with mechanisms to delay execution or end a workflow, respectively. Understanding and leveraging these top-level nodes will be key in building robust, efficient, and maintainable workflows. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/YayFz1dVbk980qXrTnHn6_image.png "Top-level nodes") - **Action** - Executes predefined or user-saved tasks. - Expands to show 'Default Actions' for typical use cases and 'Custom Actions' for user-configured tasks. - **Approve** - Introduces a manual intervention point in the workflow. - Pauses the workflow until approval is granted, enabling conditional progression. - **Workflow** - Integrates another workflow within the current one. - Facilitates modularity and the reuse of established workflows. - **Define Variables** - Sets up and initializes variables for use throughout the workflow. - Essential for defining and managing data that is used by multiple nodes. - **For Loop** - Implements iteration over a collection, array, or range of numbers. - Enables performing repetitive tasks on sets of data. - **Function** - Defines a reusable block of logic or computation. - Can accept parameters and return outputs for use in the workflow. - **Branch** - Directs the workflow along different paths based on conditional logic. - Similar to 'if-else' statements in programming, allowing for decision-based branching. - **Sleep** - Delays the workflow for a specified amount of time. - Useful for timing actions or waiting for external events. - **Terminate** - Immediately ends the workflow execution. - Can be configured to terminate on certain conditions or errors. - **While Loop** - Continuously executes a set of nodes while a specified condition is true. - Ideal for tasks where the number of iterations is not predetermined. - **Switch** - Routes workflow execution based on matched conditions. - Evaluates multiple cases and executes the first one that matches, with optional fallback behavior. - Expands to show Case Blocks for defined conditions and Default Block for unmatched cases. ## Expression Builder The Expression Builder within Kubeark is a simple, yet sophisticated feature designed to enhance the customization and flexibility of workflows, allowing users to craft complex logic and manipulate data within their workflows. This offers the ability to incorporate custom instructions or scripts directly in YAML format. This capability significantly expands the utility and adaptability of the Expression Builder, offering users a familiar and widely-used syntax to define complex logic and automation tasks within their workflows. YAML, known for its human-readable structure, makes it easier for users to craft, read, and share their custom scripts, ensuring that automation logic is both accessible and maintainable. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/9w887TPfd6XXmKnVh_NCw_image.png) Located within the arguments panel of specific nodes, the Expression Builder helps creating dynamic, context-aware actions in workflows, bridging the gap between generic automation capabilities and bespoke business requirements. By connecting the nodes together, users define the sequence and dependencies of the tasks within the workflow. This visual representation provides a clear and comprehensive overview of the entire workflow, enabling users to easily comprehend the flow of operations and identify any potential bottlenecks or areas for optimization. The workflow editor allows users to configure the properties and parameters of each node, tailoring them to suit specific requirements. This customization may involve defining input and output variables, setting conditional statements, specifying timeouts, or configuring error handling mechanisms. ## [title] Flows [path] Product Guide/Organization Administration/Untitled/ Flows are a way to describe a series of stages. A stage is a single logic or verification step. They are used to authenticate users, enroll them, and more. For instance, a standard login flow would consist of the following steps: - Identification - users identify themselves via a username or email address - Password - the user's password is checked against the hash in the database - Log in ## Flows context Flows can be configured by setting up the independent `context` which holds all of the arbitrary data about the specific flow. The flow context is created and managed by configuring policies, stages, and bindings, and it contains information about the configuration of the flow. The Identification Stage, for example, allows the definition of whether users will be prompted for an email address, a username, or both. While any data can be stored in the flow context, there are some reserved keys used by authentik stages. Below you will find a list with all the keys and their explanation. ### Common keys | **Key** | **Description** | | ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `pending_user` | The data of the user that is executing the flow. This value is not set automatically, it is set via the Identification stage | | `prompt_data` | Used in the Prompt stage; the value of any field within a prompt stage is written to the prompt\_data | | `redirect` | Stores the final redirect URL that the user's browser will be sent to after the flow is finished executing successfully. | | `pending_user_identifier` | Stores the final redirect URL that the user's browser will be sent to after the flow is finished executing successfully | | `application` | When an unauthenticated user attempts to access a secured resource, they are redirected to an authentication flow. The application they attempted to access will be stored in the key attached to this object. For example: application.github, with applicationbeing the key and github the value. | | `source` | When a user authenticates/enrolls via an external source, this will be set to the source they are using | ### Scenario-specific keys | **Key** | **Description** | | --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `consent_header` | The title of the consent prompt shown in the Consent stage. | | `consent_permissions` | An optional list of all permissions that will be given to the application by granting consent in the Consent stage | | `title` | Optional title of the form shown to the user in the Autosubmit stage. | | `url` | URL that the form will be submitted to in the Autosubmit stage. | | `attrs` | Key-value pairs of the data that is included in the form and will be submitted to the URL in the Autosubmit stage. | | `groups` | Used in the User write stage and represents the groups that the pending\_user will be added to. | | `user_path` | Path the pending\_user will be written to in the User write stage | | `user_backend` | Set by the Password stage after successfully authenticating the user and contains a dot-notation to the authentication backend that was used to authenticate the user. | | `auth_method` | Set by the Password stage, the Authenticator validation stage, the OAuth2 Provider, and the API authentication depending on which method is used. | [title] High-level Architecture [path] Architecture/ ### Overview Kubeark Platform is an multi-premise platform deployed in your environment and can be used to expose your Platform as IaaS, PaaS or SaaS for your Customers. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/7CsW5GE1eCelkOqGkBeIG_high-lev-arch.jpeg) ### Logical decomposition The Kubeark Platform utilizes a three-tier architecture, consisting of a **presentation layer**, an **application layer**, and a **persistent layer**. Presentation Layer - Web Application - REST API Endpoints - Notifications - Webhooks Application Layer - Monitoring - API logic implementation - Kubernetes Management Persistent Layer - Postgres - Redis ### Features decomposition ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/rlluScZHAsGTsqSQgSseh_feat-decomp.jpeg) [title] Concepts and Terminology [path] Product Guide/ ## The Kubernetes and Infrastructure perspectives Kubeark operates on two fundamental perspectives: the Kubernetes perspective and the Infrastructure perspective. In the **Kubernetes** **perspective**, Kubeark enables users to define and manage clusters, templates, deployments, and other Kubernetes-related entities. This aspect focuses on the orchestration and operation of containerized applications. Conversely, the **Infrastructure** **perspective** is designed to assist customers in managing their underlying infrastructure. It includes features for defining infrastructure templates, managing infrastructure deployments, and handling other infrastructure-related tasks. This dual approach allows Kubeark to provide a comprehensive solution for both application and infrastructure management. ## Templates Kubeark leverages the power of templates to make both deployment and configuration tasks easier and more efficient. Within the Kubeark ecosystem, "templates" refer to predefined configurations or scripts that serve as blueprints for deploying and managing specific components or services. These templates are designed to standardize and streamline the processes involved in setting up, configuring, and maintaining various parts of an IT environment. Considerign the two perspectives described in the beginning of this section, the Kubeark templates come in two flavors: **Kubernetes** **templates** and **Infrastructure templates**, the latter being centered around Terraform. While the core idea behind both types of templates is the same — a reusable and modifiable configuration file to streamline deployment tasks —each serves a distinct purpose. Kubernetes templates are designed to facilitate the quick and smooth deployment and orchestration of containerized applications within a Kubernetes environment. On the flip side, Infrastructure templates function more like scripts or blueprints, aiding in the definition and provisioning of various infrastructure resources. Let's see the differences between the two: - [Templates (Kubernetes)](docId\:Eud4OZB9ivS8-u3wW7-fA) - [Templates (Infrastructure)](docId\:aXq0Z6pmdsCGBURROuYWc) ### Kubernetes templates Kubernetes templates are purpose-built for the Kubernetes ecosystem. Through them, Kubeark enables users to seamlessly deploy and orchestrate containerized applications. By leveraging the power and scalability of Kubernetes, these templates assist in achieving efficient resource allocation, dynamic scaling, and robust application management within a Kubernetes environment. ### Infrastructure templates (Terraform-centric) Beyond the realm of Kubernetes, the Infrastructure templates expand deep into the broader architecture of infrastructure management and provisioning. These templates, specifically tailored for Terraform, act as scripts or blueprints for defining and provisioning infrastructure resources. They cater to tasks like provisioning virtual machines, setting up networks, orchestrating storage solutions, and more. With Terraform's declarative language and Infrastructure-as-Code (IaC) capabilities, these templates ensure that infrastructure is consistently and reliably provisioned, managed, and scaled. This dual approach enables you to efficiently manage your deployments whether they are application-centric or infrastructure-centric, providing flexibility and ease in orchestrating your entire technology stack. ## Workspaces Workspaces in Kubeark are a key organizational concept, designed to streamline the management of resources and permissions. They serve as a container for grouping related automation components. By using Workspaces, users can efficiently organize their resources based on projects, teams, or any other logical grouping, facilitating easier access and management. This structure enhances collaboration among team members and also ensures better control over access and resource allocation. Workspaces simplify the complexity of managing diverse resources, making it more manageable and intuitive for users to navigate and operate within the Kubeark environment. Detailed information here: [Workspace](docId\:rBBEpzII6ufbiJeDv5xl1) ## Workflows Workflows in Kubeark represent a powerful automation feature within each Workspace. These are essentially canvases where users can design and execute a series of automated tasks and processes. Workflows allow for the orchestration of complex operations, ranging from deployment strategies to infrastructure management, all within the context of a Workspace. They enable users to automate repetitive tasks, enforce consistency in operations, and integrate various stages of the development and deployment lifecycle. By leveraging Workflows, teams can streamline their processes, reduce the potential for human error, and ensure a more efficient and reliable operational environment within their designated Workspaces. Detailed information here: [Workflows](docId\:K5wX3wwWutvgkjpDRPV_G) ## Forms Forms in Kubeark are interactive components used within Workspaces and Workflows to capture user input and configurations. They provide a user-friendly interface for entering data, setting parameters, and making selections that influence the behavior of Workflows and other Kubeark functions. Forms simplify the process of configuring complex tasks by presenting options in an easily understandable format, ensuring that users can input the necessary information without requiring deep technical knowledge of the underlying systems. This feature enhances the accessibility and efficiency of Kubeark, making it more approachable for users of varying technical expertise. Detailed information here: [Forms](docId\:Fc-zxJNhs77M7CIPNB0eR) ## Functions Functions in Kubeark refer to discrete, reusable operations or actions that can be integrated into Workflows. They are essentially building blocks designed to perform specific tasks within the automation process. Functions can range from simple actions like sending notifications to more complex operations like deploying a cluster or updating a database. The key advantage of Functions is their modularity and reusability, allowing users to create more efficient and maintainable Workflows. By incorporating these Functions into different Workflows, users can optimize their automation processes, reduce redundancy, and ensure consistency across various tasks and projects within Kubeark. Detailed information here: [Functions](docId\:SONgAEeCZqqx1kXGcdCqF) ## Vault Vault in Kubeark is a secure storage feature for managing sensitive data such as credentials, tokens, and keys. It's designed to enhance security by providing a centralized and encrypted location for storing confidential information. Vault ensures that sensitive data is not exposed in scripts or configurations, reducing the risk of unauthorized access or breaches. It supports access controls and audit logs, allowing administrators to control who can access the stored information and track usage. This feature is key for maintaining security best practices within Kubeark, especially when managing infrastructure and applications that require high levels of data protection and compliance. Vault's integration into the Kubeark platform ensures secure data management, making it more convenient and reliable for users. In Kubeark, the Vault comes in two flavors: - [Global Vault](docId:2rllb1GL2dwiCGxPEZHM7) - [Local Vault](docId:6UOO8pp2iYgibUmgRCNwi) [title] Federation and Single Sign On (SSO) [path] Product Guide/Organization Administration/Users/ Kubeark offers a variety of capabilities for Single Sign-On (SSO) and social logins, making it easy to integrate with popular identity providers such as Google and Facebook. With SSO, users can sign in once and access multiple applications without having to repeatedly enter their credentials. This is not only convenient for users, but also helps improve security by reducing the number of passwords users need to remember. Kubeark allows users to authenticate with their existing social media accounts instead of creating new credentials. This makes it easy for users to get started with your application and can help increase user engagement. ## How to enable? **Step 1:** On the main Kubeark page, go to `User Management` and select `Users`. From the Users page, on the top left corner of the workspace, select **IDP.** ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/GQdaXkbO0WAg8uLYvQeqx_sso-s1.jpeg) **Step 2:** This will take you to the `User Interface` of the Identity Management console. From the top right corner of the screen, select `Admin interface` :::hint{type="info"} The Kubeark Identity console presents two different views, which are determined by the role of the user who is accessing them: - **User Interface** - this is the default screen for user accounts - **Admin Interface** - this is the identity management console dedicated to organization admins ::: ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/xblw7eS7wKqfpAmfA61Ka_sso-s2.jpeg) **Step 3:** Within the *Admin Interface*, go to `Directory` > `Federation & Social login` ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/g9oQfuBB2eRBheREPkr9y_sso-s3.jpeg) **Step 4:** Here you will see a list of all active sources of identities. To enable a new Identity Provider, select `Create` ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/ZhTQ4E-DKuUQIOYlGQ1Rf_sso-s4.jpeg) **Step 5:** Choose your preferred source from the list of available providers and click `Next` ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/xomZgDJuQ9T_szoaKUOeU_sso-s5.jpeg) **Step 6:** In the source configuration prompt, enter all details required for configuring the new source depending on your previous selection. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/LdpiGkIN23laKKDAofhLa_sso-s6.jpeg) :::hint{type="info"} When configuring federation and social login, it is important to keep in mind that the detailed configuration process may vary depending on the specific identity provider being used. For example, if you are integrating with Azure AD, you will need to follow the respective steps to enable the service from the Azure portal. Similarly, other identity providers may require different steps or configurations. Therefore, it is recommended to refer to the official documentation or support resources provided by the identity provider to ensure that the necessary configuration is completed correctly. By following the **provider-specific guidelines**, you can ensure a smooth and secure integration between your application and the identity provider. ::: [title] Prompt stage [path] Product Guide/Organization Administration/Untitled/Untitled/ ## Prompt types and attributes The prompt can be any of the following types: | **Type** | **Description** | | ----------------------- | ------------------------------------------------------------------------------------------ | | `Text` | Arbitrary text. No client-side validation is done. | | `Text (Read only)` | Same as above, but cannot be edited. | | `Text Area` | Arbitrary multiline text. No client-side validation is done. | | `Text Area (Read only)` | Same as above, but cannot be edited. | | `Username` | Same as text, except the username is validated to be unique. | | `Email` | Text input, ensures the value is an email address (validation is only done client-side). | | `Password` | Same as text, shown as a password field client-side, and custom validation (see below). | | `Number` | Numerical textbox. | | `Checkbox` | Simple checkbox. | | `Radio Button Group` | Similar to checkboxes, but allows selecting a value from a set of predefined values. | | `Dropdwon` | A simple dropdown menu filled with predefined values. | | `Date` | Same as text, except the client renders a date-picker | | `Date-time` | Same as text, except the client renders a date-time-picker | | `File` | Allow users to upload a file, which will be available as base64-encoded data in the flow . | | `Separator` | Passive element to group surrounding elements | | `Hidden` | Hidden input field. Allows for the pre-setting of default values. | | `Static` | Display arbitrary value as is | | `authentik: Locale` | Display a list of all locales authentik supports. | The prompt has the following attributes: | **Attribute** | **Description** | | --------------- | ---------------------------------------------------------------------------------------------------------------- | | `field_key` | The field name used for the prompt | | `label` | The label used to describe the field | | `required` | A flag which decides whether or not this field is required | | `placeholder` | A field placeholder shown with the input field | | `initial_value` | The prompt's initial value. It can also be left empty, in which case the field will not have a pre-filled value. | | `order` | The numerical index of the prompt. This applies to all stages which this prompt is a part of. | ## Validation Policies can be used to perform further validation. As an example, to validate that two password fields are identical, you can create the following expression policy: ```yaml if request.context.get('prompt_data').get('password') == request.context.get('prompt_data').get('password_repeat'): return True ak_message("Passwords don't match.") return Falsel ``` [title] The Workflow Editor [path] Automation Menu/Workflows/ ## Overview The **Workflow Editor** is a user-friendly interface for creating, managing, and visualizing workflows. The workflow editor enables users to design and manage workflows visually, providing a simple and intuitive canvas for creating complex workflows. With its drag-and-drop functionality, the workflow editor allows users to effortlessly arrange and connect nodes, which represent individual steps or tasks within the workflow. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/ujyX3WMJ2IxIR-vXJMiep_image.png) With the ability to design workflows visually and manipulate nodes through drag-and-drop interactions, the workflow editor eliminates the need for complex scripting or coding. This streamlines the process of building and modifying workflows, making it accessible to a wider range of users, including those without extensive programming expertise. ## The interface The Workflow Editor interface in Kubeark is a user-friendly environment designed for creating and managing Workflows. It is structured to facilitate ease of use while offering comprehensive functionality. Here's an overview of its key components. **Kubey AI:** By integrating AI-powered conversational capabilities directly into the workflow environment, users can effortlessly query the system, receive intelligent suggestions for optimizing their workflows, and resolve issues in real time. This option serves as a virtual assistant and empowers you to harness the full potential of the Kubeark platform **Code editor:** This editor allows for viewing and editing the workflow manifest, offering a more technical and detailed approach to workflow management. Refer: [The Code Editor](docId\:BkFTs5TAtm8xN8tHJMkUC) **Working Area: **The central part of the editor, this is where the construction of the workflow takes place. Users can arrange, connect, and configure the nodes and actions dragged from the left side panel, visually designing the workflow’s structure and flow. **History:** By clicking this button, users can view the execution history of the workflow. This historical data is important for analyzing past operations, troubleshooting issues, and understanding the workflow's performance over time. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/59qiBQ-lgvr4ttErLU3_i_image.png) **Webhooks**: This opens a popup window where users can setup new webhooks. The creation process involves specifying details such as the description, response payload format (YAML/JSON), and a code snippet window. Additionally, users can set up Access Control Lists (ACL) by adding groups, headers, and values, ensuring secure and controlled webhook operations. See [Webhooks](docId:9r0vWXQTUIv3bvPgq6FXI) ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/NYKaIknh4wN2ZE0lyCBpD_image.png) The webhooks trigger option allows the workflow to respond to HTTP callbacks. Users can configure external systems to send webhook events, which in turn trigger the execution of the workflow. This integration provides flexibility in initiating workflows based on specific events or notifications from various external sources. By leveraging webhooks, users can seamlessly connect their workflows with other systems, enabling powerful automation and orchestration capabilities **Code editor:** For users who prefer to work directly with the workflow’s code, this button opens up a code editor. This editor allows for viewing and editing the workflow manifest, offering a more technical and detailed approach to workflow management. It caters to users who are comfortable with direct code manipulation or who need to make advanced customizations. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/1ZKsx7R1atvagCX9r5FOA_image.png) The workflow editor comprises a diverse range of essential components that offer extensive functionality for workflow design and execution. These components include nodes, actions, triggers, and other related elements, enabling users to construct and customize workflows according to their specific requirements. [title] Templates (Kubernetes) [path] Environments Menu/Kubernetes/ **Save valuable time and reduce the risk of errors from one centralized place. Templates enable you to customize everything needed to fit your pipeline needs. Define it once and use it multiple times!** ## Overview Collaboration, communication, and integration play a vital role in achieving success in the DevOps landscape. By focusing on these elements, teams can enhance their performance and ensure the quality of their processes and pipeline. These aspects are critical for achieving high performance and quality assurance, and by optimizing them, teams can experience a positive impact on their overall efficiency and effectiveness. With this in mind, Kubeark makes use of **Templates.** Templates in Kubeark are pre-constructed configurations that include all the resources necessary to run a specific workload or application. They are designed to save time and reduce errors when scaling, by providing all the necessary infrastructure, platform, and software components. They are easy for users to implement and get started with. The **Templates** page within the Kubeark Platform offers an intuitive, easy-to-use interface for defining and managing templates. There are two types of templates that Kubeark uses to enable a smooth experience with your projects. Going further, let's see what these are: ::::VerticalSplit{layout="middle"} :::VerticalSplitItem Manifests A Kubernetes `manifests` represents the specification of an `API object` in JSON or YAML format. In a manifest you can specify a desired state of an object that Kubernetes will create and maintain when the manifest is applied to the specific Kubernetes cluster. ::: :::VerticalSplitItem Charts A `chart` represents a collection of files that describe a related set of Kubernetes `API objects `or resources. The template language of a chart is implemented in typed Go programming language ::: :::: *** ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/FjB7mp0VlXrDeixYWrh4i_templates.jpg) *** ## How does it work? In order to define a template in Kubeark, there are a few important object types that we need to consider: ### The main arguments section These are **mandatory** **inputs** that need to be provided in order to define a functional deployment. Arguments will enable you to define what values can be passed along to your pipeline. | **Argument** | **Description** | | -------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Name` | This is the unique name of the defined template | | `Template group` | The template group to which the new template will belong | | `Cluster group` | The cluster group to which the new template will belong | | `environment_action` | This argument allows adding business logic for the environments lifecycle, and can be defined through: -> terminate - This is when the environment is terminated when the default\_time, additional\_time and grace\_time reach 0 seconds
-> `Manual` 
-> `Stop`
-> `Terminate` - This downscales to 0 all the resources that can be scaled to 0 (e.g. Deployments*, *StatefulSets*, *ReplicaSets, etc) | | `Status` | The template status is an unique value from an allowed list of values. These can be:
->`Active` -* Production ready* 
->`Disabled` - *In development* | | `Scope` | This is a boolean value which defines the type of template based on your collaboration preferences or needs:
-> `public` - *the endpoint is exposed in the public *templates* list *
* -> *`private` - templates* are exposed internal only* | | `Owner` | This field defines the `user` which created the template | | `Tags` | Option to add a custom tag to your template for easy reference | | `Description` | Add a custom description about the template | | `default_time` | Represents the default time until an environment\_action is triggered. The logic behind this parameters is that we want on-demand disposable containers triggered by external or internal actions like paying an invoice, closing or opening a contract, etc | | `additional_time` | Represents an additional time when the default time is reached. This is used as a failsafe mechanism before triggering the environment\_action | | `grace_time` | Represents the grace period before the environment is deleted or terminated | | | | *** ### **Extra-Arguments** These are additional arguments that can be added which offer you more control over the values that can be passed to your pipeline. They are designed to encapsulate dynamic or specific template arguments. **Form composer - **When creating a template, you have the option to provide additional details using a form composer. The form composer can be used from the main template creation page by selecting the "Insert Field" button. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/zVA_kZY3otr70x06R3ZEq_image.png) Here are some of the fields you can include: - `Key`: A unique identifier or name for the field. - `Id`: An identifier that helps uniquely identify the field within the form. - `Name`: The name or label of the field as it will appear in the form. - `Title`: A title or description that provides further information about the field's purpose. - `Input Type`: Specifies the type of input expected in the field, such as "text" for plain text input. - `Min Length and Max Length`: Define the minimum and maximum lengths allowed for the input in characters. - `Label`: A descriptive label for the field, providing context or guidance to the user. - `Pattern`: If applicable, a regular expression pattern that defines the expected format for the input. - `Value`: An initial or default value for the field, if needed. - `Disabled`: A boolean (true/false) value indicating whether the field is initially disabled or not editable. - `Required`: A boolean value specifying whether the field must be filled out by the user *Example: Let's consider a web service solution with an ingress where a different ingress endpoint for each deployment is required. Here you will define an argument with a default value which can be overridden at the deployment step.* **Chart information** - this section includes essential details related to charts and repositories in the context of Kubeark template creation ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/8dYljinpKxFHbhoGBxWUp_image.png) The arguments you can include: - `Chart Information Name`: A user-defined name or identifier for the chart. It helps users easily recognize and reference the specific chart associated with the template. - `Repository Name`: The name of the repository or source where the chart is hosted. - `Repository URL`: The repository URL specifies the web address or location where the chart repository can be accessed. - `Path`: The path field defines the directory or subdirectory within the repository where the specific chart files are located. **Additional parameters** - Variables are used to generate random data. You can use them in the values field of the additional parametewrs section. You can combine them with any other values. For example, \{\{set\_string}}-test the result will be a random string followed by the word test. You can also use them in a payload from a value of extra arguments, combined with other values or predefined variables. The following predefined variable categories are available: ->`Infra` ->`User` ->`Function` Additional parameters can also be added, the platform supporting various formats such as *string, numeric, JSON, Code, List or Boolean* [title] Template Versions [path] Environments Menu/Kubernetes/ The templates within the Kubeark support an unrestricted number of versions, however, only one version can be designated as active at a time. ### Considerations - Users can choose or create a new version from the [Template Groups](docId\:K_kBPnulstc8byJkKHTtX) page. - Each `Deployment` is limited by the number of [Templates (Kubernetes)](docId\:Eud4OZB9ivS8-u3wW7-fA) available, which is determined by the license associated with the product. - Each Template can have an unlimited number of versions, but only one version can be active at a time. - Only the active version of a Template can be deployed. - Users have the option of migrating a deployment from a previous version to the active version. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/IuUf4_DetNzRXj1KFF5v8_templ-versions.png) ### Benefits The following benefits are available when using the Kubeark platform: - The ease of which Templates can be moved between Groups enables users to manage multiple deployments without the need for rework, manual copying or duplication. - The ability to update all deployments associated with previous versions of a Template with a few clicks simplifies the application update management. - Existing deployments are protected by preventing the deletion of versions with associated apps, which ensures the stability and reliability of existing systems. - The dry test functionality allows users to validate a version's functionality before deploying it, lowering the risk of unexpected issues or failures. By detecting potential problems early in the deployment process, this feature can save time and resources. [title] Software Requirements [path] Getting Started/Prerequisites/ The software requirements section outlines the necessary system and software configurations for successful deployment and operation of Kubeark. This includes information on supported operating systems, web browsers, and any other dependencies required for optimal performance. :::hint{type="info"} It is important to review and confirm that your system meets these requirements before proceeding with the installation and setup of Kubeark. ::: ### Operating System | Operating System | - Ubuntu - 20.4 and above - Debian - 12 and above - CentOS/RHEL 7 - SUSE Linux Enterprise Server 15 | | ---------------- | --------------------------------------------------------------------------------------------------- | | OS Prerequisites | * SSH * Time synchronization (NTP) for all nodes | ### Other dependencies `kubecli` can install Kubernetes and Kubeark together. Some dependencies need to be installed before installing kubernetes after version 1.18. You can refer to the list below to check and install the relevant dependencies on your node in advance. | | Kubernetes Version 1.8 or above | | --------- | ------------------------------- | | socat | Required | | conntrack | Required | | ebtables | Optional but recommended | | ipset | Optional but recommended | | ipvsadm | Optional but recommended | [title] Deleting a Deployment [path] How to's/ A Kubeark deployment can be easily removed in just a few simple steps. ::::WorkflowBlock :::WorkflowBlockItem From the `Templates Management` main menu, select `Deployments` ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/vlqnlRZsukWFtsc3p2W8W_del-depl-1.png" signedSrc size="54" width="518" height="334" position="center" caption} ::: :::WorkflowBlockItem Here you will see a list of all your Deployments as well as relevant information such as status, resource utilization and others. Select the deployment you want to be removed. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/WQwql4sPttO1q9e_WLiiy_del-depl-2.png) ::: :::WorkflowBlockItem Select `Delete` ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/d9QziU6PXlQGmyxUrtp7y_del-depl-3.png) ::: :::: [title] Dashboard [path] Analytics/ Resources such as CPU, Memory, and Network usage are displayed in detail on the `Analytics` page under the **Dashboard** menu. This information can help users identify resource constraints and optimize their applications. The following analytics are available: 1. A **performance chart** is available at the top of the page, which displays performance data, over a selectable period of time (last 7 days, last 3 days, last day, last 12 hours, last 6 hours, or last hour). Additionally, the graph can be filtered to display performance data for CPU, RAM, or network performance, providing a comprehensive view of the application's performance over time. 2. **CPU**: A detailed view of the application's CPU usage, including usage metrics such as the number of requests, limits, and overall utilization. This data can be used to pinpoint performance bottlenecks and improve application performance. 3. **Memory**: A detailed view of the application's memory usage, including metrics such as the number of requests, limits, and overall utilization. This data can be used to pinpoint performance bottlenecks and improve application performance. 4. **Pods**: A view of the number of pods in use and the overall number of available pods. This information can be used to manage the capacity of the cluster and ensure that the application has enough resources to run efficiently. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/ygoAgDlaWaaHWHvUgzYRu_image.png) [title] Environments Menu [path] / [title] Installation guide [path] Getting Started/ :::hint{type="info"} This guide applies to the On-prem/Cloud deployment (customer managed) models ::: ## Step 1 - Infrastructure setup Prior to the installation of Kubeark, it is important to ensure that the requisite infrastructure is appropriately configured. Options for this infrastructure include physical machines, virtual machines, or a private cloud solution to host the necessary resources. **Prerequisites***:* ::::WorkflowBlock :::WorkflowBlockItem **Resource allocation: **A minimum of 3 machines need to be configured ::: :::WorkflowBlockItem **HW/SW Requirements:** Ensure that each machine meets or exceeds the minimum hardware requirements such as CPU, RAM, and disk space. - [Hardware Requirements](docId\:MVYi8prmPe3iZgG_ZbipK) - [Software Requirements](docId\:A4ygr3mSyOgaUFLEqSDZi) ::: :::WorkflowBlockItem **Network Configuration** **and Firewall: **please follow the recommended setup here - [Network configuration & Firewall](docId\:El7fePCPQK1lovICYTbPj) ::: :::: ## Step 2 - Configuration file setup Once the necessary infrastructure has been established, the subsequent step involves generating a configuration file. This file is a mandatory component in tailoring the Kubeark installation process to align with your organization's requirements. ::::WorkflowBlock :::WorkflowBlockItem **Create Configuration File**: Utilize a text editor to generate a new configuration file, ensuring it is saved with the relevant file extension, such as YAML. ::: :::WorkflowBlockItem **Edit Parameters**: Incorporate the requisite settings into the configuration file to reflect the specifications of your operational environment. Such settings may include machine IP addresses, network configurations, and additional variables integral to the system's proper functioning. - Mandatory parameters - Optional parameters ```javascript # Sample Kubeark Configuration File # General Settings name: "MyKubearkCluster" version: "1.0.0" # Networking network: type: "flannel" podCIDR: "10.244.0.0/16" serviceCIDR: "10.96.0.0/12" # Master Node Configurations master_nodes: - hostname: "master1" ip: "192.168.1.101" - hostname: "master2" ip: "192.168.1.102" # Worker Node Configurations worker_nodes: - hostname: "worker1" ip: "192.168.1.201" - hostname: "worker2" ip: "192.168.1.202" # Storage storage: type: "local" path: "/var/lib/kubeark" # Custom URL (Change this to your custom URL) custom_url: "https://mycustom.kubeark.url" # Additional Settings additional_settings: log_level: "info" enable_metrics: true ``` ::: :::WorkflowBlockItem **Save and Copy**: After customization, save the configuration file. Then securely **copy this file onto each machine** in your infrastructure setup. ::: :::: ## Step 3 - Run the Installation ### 3.1 Online installation For an online installation of Kubeark, you will need to download specific packages and use SSH for secure data transfer and commands. The process involves both local and remote operations on your infrastructure nodes. ::::WorkflowBlock :::WorkflowBlockItem **Receive Custom URL**: Once your Kubeark license is activated, check your email for a message containing your unique custom URL. This URL is specifically generated for your organization and will guide you through the online installation process. The URL would typically look like this: Kubeark Installer 3.0.0-beta.4566 ::: :::WorkflowBlockItem **Set permissions**: Open your terminal and navigate to the directory where the installer binary is saved. Use the `chmod` command to set the necessary execution permissions: ```windows chmod +x kk-* ``` ::: :::WorkflowBlockItem **Prepare SSH Key**: Ensure you have an SSH key pair to securely communicate with your nodes. If not, generate one and then use scp to copy the private key to your first infrastructure node. This will be used to comunicate with the other nodes, as alternative you can use user/pass but is not that secure ```windows scp ~/.ssh/id_ecdsa kubeark@192.168.x.1:~/.ssh/id_ecdsa ``` ::: :::WorkflowBlockItem **Transfer Configuration and Installer**: Use `scp` to copy the configuration file and installer binary to the target node. ```windows scp online-install.yaml kubeark@192.168.x.1:~/ scp kk-3.0.0-beta.4566 kubeark@192.168.x.1:~/ ``` ::: :::WorkflowBlockItem **SSH into the Node**: Connect to the first infrastructure node using SSH. Replace 192.168.xx.xx with the IP address of the node you're connecting to: ```windows ssh kubeark@192.168.x.1 ``` ::: :::WorkflowBlockItem **Run the Installer**: Execute the installer with the following command. This uses the transferred configuration file (e.g. *online-install.yaml*) and initiates the cluster creation process: ```windows sudo ./kk-3.0.0-beta.4566 create cluster -f online-install.yaml -y ``` ::: :::: ### 3.2 Offline (AirGapped) installation The offline installation method is intended for environments without internet connectivity. Unlike the online installation, this method requires you to download the complete installation package image files, which are approximately 5GB in size. You'll then run the installation locally on your target infrastructure nodes. :::::WorkflowBlock ::::WorkflowBlockItem **Download Required Files**: Navigate to the Kubeark download page and download the installer and image files. e.g. *kk-artifact-3.0.0-beta.4566.tar.gz* :::hint{type="info"} This specific download page URL will be provided to the customer through an email communication following the license activation. ::: :::: :::WorkflowBlockItem **Set permissions**: Open your terminal and navigate to the directory where the installer binary is saved. Use the `chmod` command to set the necessary execution permissions. ```windows chmod +x kk-* ``` ::: :::WorkflowBlockItem **Transfer Files to Node**: Use a secure method, such as `scp`, to transfer the downloaded installer and image files to the first infrastructure node. ```windows scp kk-3.0.0-beta.4566 kubeark@192.168.x.1:~/ scp kk-artifact-3.0.0-beta.4566.tar.gz kubeark@192.168.x.1:~/ ``` ::: :::WorkflowBlockItem **Prepare SSH Key**: Ensure you have an SSH key pair to securely communicate with your nodes. If not, generate one and then use `scp` to copy the private key to your first infrastructure node. This will be used to comunicate with the other nodes, as alternative you can use user/pass but is not that secure ```windows scp ~/.ssh/id_ecdsa kubeark@192.168.x.1:~/.ssh/id_ecdsa ``` ::: :::WorkflowBlockItem **Initialize the local container registry: **Before running the installer to create your cluster, you'll first initialize a local container registry and populate it with the necessary images. These commands also use the *kk-artifact-3.0.0-beta.4566.tar.gz *package, which should be located in the same directory as your *offline-install.yaml *file. ```windows sudo ./kk-3.0.0-beta.4566 init registry -f offline-install.yaml -a kk-artifact-3.0.0-beta.4566.tar.gz ``` ::: :::WorkflowBlockItem **Push the artifact images to the registry** ```windows sudo ./kk-3.0.0-beta.4566 artifact image push -f offline-install.yaml -a kk-artifact-3.0.0-beta.4566.tar.gz ``` ::: :::WorkflowBlockItem **Create the cluster using the local registry and packages** ```windows sudo ./kk-3.0.0-beta.4566 create cluster -f offline-install.yaml -a kk-artifact-3.0.0-beta.4566.tar.gz --with-packages -y ``` ::: ::::: ## Step 4 - Post-installation Validation After successfully completing the installation of Kubeark, please validate that the deployment is operational and configured as expected. This step involves accessing the custom Kubeark URL that you specified earlier in the configuration file (refer to Step 2). By doing so, you can verify that the service is accessible and functioning correctly. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/IPKKh3OnyIFfU4lkcs-Ra_validation.png) [title] Certificates [path] Product Guide/Organization Administration/Untitled/ Certificates are required in the following scenarios: - Sign in and verify SAML Requests and Responses - Sign JSON Web Tokens for OAuth and OIDC - Connect to remote docker hosts using Docker integration - Verify LDAP server certificates - Encrypt outpost endpoints ### Default Certificate Kubeark Identity generates a self-signed certificate on the first start, which is valid for 1 year and can be used as a default for all OAuth2/OIDC providers. This certificate is also usable for SAML providers/sources, although it should be rotated regularly since some SAML applications require valid certificates. Kubeark allows users to generate a longer-validity certificate for SAML use-cases. ### External certificates Kubeark allows for the use of externally managed certificates through the discovery feature. For docker-compose installations, the /certs directory can be used as an output directory for certbot. For Kubernetes, custom secrets/volumes can be mapped under /certs. Single files can also be bind-mounted into the folder following a specific naming schema. Files in the root directory will be imported as certificate or private key based on their filename and contents. If the file is named fullchain.pem or privkey.pem, they will get the name of the parent folder. Files can have any arbitrary file structure and extension, but if the path contains "archive," the files will be ignored to better support certbot setups. ```text certs/ ├── baz │ └── bar.baz │ ├── fullchain.pem │ └── privkey.pem ├── foo.bar │ ├── fullchain.pem │ └── privkey.pem ├── foo.key └── foo.pem ``` ### Manual import Certificates can also be imported manually. To do so, run the following command within the worker container ```text ak import_certificate --certificate /certs/mycert.pem --private-key /certs/something.pem --name test ``` ### Web Certificates The default webserver certificate can be configured if you wish to create a very compact and self-contained install. **Step 1**: Encrypt certificates with this setup, using certbot, you can use this compose override (create or edit a file called `docker-compose.override.yml` in the same folder as the docker-compose file) ```text version: "3.2" services: certbot: image: certbot/dns-route53:v1.22.0 volumes: - ./certs/:/etc/letsencrypt # Variables depending on DNS Plugin environment: AWS_ACCESS_KEY_ID: ... command: - certonly - --non-interactive - --agree-tos - -m your.email@company - -d authentik.company # Again, match with your provider - --dns-route53 ``` **Step 2**: run `docker-compose up -d`, which will start certbot and generate your certificate. Within a few minutes, you'll see the certificate in your identity interface. (If the certificate does not appear, restart the worker container. This is caused by incompatible permissions set by certbot). [title] Settings Menu [path] / ## Overview Kubeark Vault offers a centralized repository for managing certain values that are used across multiple components like database credentials, API keys, and environment-specific settings. This ensures that every component of an application references a singular, consistent source for its configurations. Vault centralizes and manages configuration values that are essential for various components of your application. By simplifying the process of defining, scoping, accessing, and managing these variables, Vault enhances the overall efficiency and security of your deployments. This platform ensures a reliable and streamlined approach to handling configuration values, promoting consistency and reducing maintenance efforts. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/Pu18Iw3Zq0kAAxJ_-lvvr_vault1.png) ## Capabilities 1. **Cluster Management**: Vault's cluster management section provides users the tools to define, edit, and oversee variables associated with different clusters. Ensure each cluster operates with its designated configurations and accesses the correct resources. 2. **Infrastructure (Infra)**: This is where users manage the variables related to infrastructure setups. Whether you're working on networking configurations or storage parameters, the 'Infra' section makes it straightforward. 3. **Workflows**: Streamline your processes by setting up and managing workflow-specific variables here. By defining precise configurations, you ensure each workflow runs seamlessly and reliably. 4. **User**: Personalize user experiences or manage user-specific data by employing the user variables section. This feature ensures individual users or groups operate under their specific parameters. 5. **Function**: Integrate and manage specific function-related variables with ease. Whether it's a custom function or a predefined one, ensure it has the right settings to execute correctly. 6. **Template Group**: Organize and manage variables related to different template groups. Tailor configurations to cater to specific template group needs, ensuring optimal deployment and functioning. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/KrlCFl4IXdG7TfjC3p9sp_vault2.png) ## How to create a Vault key? **Step 1 - Access the Vault**: navigate to the Settings menu in the main application dashboard **Step 2 - Initiate Key Creation: **once inside the Vault section, select Create Key.  ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/gt38mn8cy_Ngoaen8vbue_vault-key-creation.png) **Step 3 - Fill in the Key details**: Upon selecting Create Key, a prompt will open, allowing you to enter the desired arguments for the key creation  ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/6T-A7sbxIid-XcuRqaC1o_vault-key-details.png) | **Argument** | **Description** | | ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Name` | Enter the desired name for your key. This will be how you reference it in future | | `Value` | Input the actual data or value for your key. This can be any string of text or numbers. | | `Is Secret?` | You will see a toggle switch labeled "Yes/No". If your key contains sensitive information that should be hidden or encrypted, toggle this to "Yes".  | | `Description` | Provide a brief description of the key. This can be helpful for others who may use this key, or for you to recall its purpose later. | | `Scope` | Here, you can define the scope of the key's applicability. Choose from the following options based on where you want this key to be used:-> Cluster-> Infra-> Workflows-> User-> Function-> Template Group | **Step 4 - Save and Confirm:** Once you have filled in all the required arguments, click on **Save**. [title] Custom Actions [path] Automation Menu/Workflows/About Nodes/Actions/ **Custom Actions** offer a layer of customization, allowing users to script and tailor actions according to specific business needs. Kubeark's expression builder is a key feature here, enabling the creation of bespoke automation solutions by defining custom logic and parameters. [title] Release Notes [path] / [title] Features Menu [path] Architecture/Platform Interface/ This menu is active across all Kubeark Platform pages and offers you the possibility to navigate through the functional menus and settings. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/Im3LYsM6sGCYOa3rkCpFX_image.png) The following menus are available: | **Options** | **Description** | | --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Analytics` | The first interaction with the Kubeark Platform after successful Authentication is the Analytics page. This section includes:
* **Dashboard** * **Usage** * **Jobs** | | `Automation` | The Automation menu contains three main sections:
* **Workspace - **This section allows users to create and manage workspaces, which are customizable environments where teams can collaborate, deploy applications, and automate workflows. * **Forms - **The Forms section enables the creation and customization of digital forms, making it easy to collect structured data from users within the Kubeark platform. * **Functions - **This section empowers users to automate and orchestrate various processes using Functions | | `Environments` | The Environment menu serves as a central hub for managing and configuring various aspects of your digital environment, and contains the following submenus
* **Kubernetes** * **Infrastructure** * **Artifacts** | | `Cluster Management` | This section includes:
* Cluster group * Clusters | | `Settings Management` | The Settings page offers administrative functions for managing:
* **Workspaces** * **Settings** (platform settings) * **Vault** | | `Audit` | - the Logs page | | `User Management` | This section contains the user administration menus:
- **Users** page - **Roles** page | | | | [title] Template Groups [path] Environments Menu/Kubernetes/ :::hint{type="info"} Each `Deployment` is subject to a limit on the number of `Templates`, which is based on the aplicable license. Each Template can have an unlimited number of `Template Versions`, however, only one version can be active at a time. The active version of the Template is the only version that can be deployed. Additionally, you have the option to update the applications of a previous version to the current active version. ::: ## Overview Kubeark introduces **Template Groups** as a fundamental aspect of the platform's deployment management system. In the feature decomposition structure of the Kubeark platform, the `Template Groups` feature acts as the top layer. Users can simply track and manage connected deplpyments inside a single, manageable unit thanks to this high-level perspective, which offers a thorough and systematic approach to managing deployments. `Template Groups` offer a hierarchical structure for managing and organizing Kubeark templates, which aims to help efficientize the management of deployments. By enhancing visibility and control over the deployment environment, this feature helps users monitor and maintain their installations more effectively. An application's desired state as a collection of persistent objects in the Kubernetes ecosystem is represented by each product in the Template Groups menu. Each group is a collection of connected Kubeark deployments. A high-level view of deployments is provided by the `Template Groups` feature, which lowers the risk of errors, makes it simpler to track and manage deployments, and also helps you save time. The `Template Groups` feature also gives users a single area from which to access and manage their deployed applications, enhancing teamwork and collaboration and allowing users to collaborate on deployments inside the same product. This feature's adaptability and contemporary design aims to provide a more consolidated and structured deployment procedure. *** ## Creating a new Template Group **Step 1:** On the `Environments` section, under `Kubernetes`, you will find the `Templates groups.` Select `Create Template Group` ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/b2gG00SXpjuX9XZG2P2t4_image.png) **Step 2:** In the group creation form, fill out the following details: | **Argument** | **Description** | | ------------- | ---------------------------------------------------------------------------------------------------------- | | `Name` | Provide a unique and descriptive name for the template group. The name must contain at least 2 characters. | | `Status` | Choose between "Active" or "Disabled" to set the availability of the group. | | `Description` | Add a brief summary of the group and its purpose to provide context for other users. | | `Tags` | Assign relevant tags to help categorize and organize the product list within the platform. | ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/obyjDNKk2_tXlkkddcIn3_templ-grp2.png) **Step 3**: Once all of the required information has been entered, click the "Save" button to create the new Group. Upon successful creation, the Group will be added to the main list within the user's workspace. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/8L1lAbCgygfGMFimTYViC_templ-grp3.png) ### Adding Templates to the Group **Step 4**: The next step after creating a new Group is to assign Templates to it. To do this, either add a fresh Template to the list already accessible, or upload an existing Template. The Templates are made up of configuration files with all the resources needed for a particular deployment. Kubeark offers multiple ways of adding templates to the newly created Template Group. - **Create Template**: Using this option, you can start from scratch and define all the resources needed for a certain deployment, both mandatory and optional. This feature gives users total control over the template's setup, allowing them to tailor it to their specific needs. Please refer to the [Templates (Kubernetes)](docId\:Eud4OZB9ivS8-u3wW7-fA) section for detailed instructions on how to create a template. - **Upload Template**: With the Upload Template option in Kubeark, you can efficiently add pre-existing templates in the form of a JSON file. This option allows you to import templates that you have previously created or saved, saving you time and effort in the process. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/WmFADieQLHZq94v2xlgnq_add-tmpl-1.png) - **Raw**: This option allows users to manually enter and edit the template configuration in real-time, either in JSON or YAML format. This feature provides an efficient way to quickly make changes to the template configuration, especially when the desired changes are simple and require minimal effort. ```json //sample code block "name": "", "chart": { "name": "", "repo_url": "", "path": "", "repo": "" }, "product_id": 16, "parent_template_id": 0, "owner": "sample.user", "description": null, "active": false, "extra_args": {}, "public": true, "start_time": null, "default_time": "5", "additional_time": "0", "grace_time": "0", "tags": [], "environment_action": "manual" ``` [title] Logs (Global) [path] Audit/ The Logs page in the Kubeark Platform provides users with access to detailed application and audit logs, as well as the ability to export these logs for further analysis or record-keeping. The application logs provide information on the actions and events that occur within the platform, while the audit logs track changes made to the platform's configuration and user management. These logs can be viewed and filtered on the Logs page, and can also be exported in various file formats for further analysis or record-keeping. **To access the platform logs, go to the **`Audit`** section of the main feature menu and select **`Logs`**.** ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/_IVDKB2Cx4rG_AKsAohNU_image.png) Here three types of logs are available: - **Audit Logs** - **Platform Logs** - **Exported Logs** ::::Tabs :::Tab{title="Audit Logs"} ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/PIuudVIEsmoTSHicUlqNL_audit-logs.jpg) ::: :::Tab{title="Platform Logs"} ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/NpRQ9Jf78UmE3PwrUHjf8_logs-platform.jpg) ::: :::Tab{title="Exported Logs"} ::: :::: ### Audit Logs Kubeark provides a detailed list of actions that have been performed within the platform, including: 1. **Description**: A brief description of the action that was performed. 2. **Changed Values**: The specific values that were changed as a result of the action. 3. **IP Address**: The IP address of the device or user that performed the action. 4. **User Agent**: The browser or application used to perform the action. 5. **Created**: The date and time the action was performed. This list of actions can be found on the Logs page of the Kubeark Platform and can be filtered and searched to find specific actions. It provides a comprehensive view of all the actions that have been performed within the platform, allowing users to track and troubleshoot any issues that may have arisen. The information provided in the list of actions is useful for monitoring platform activity, auditing changes and troubleshooting issues. It also allows administrators to see what actions were performed by which user and when. ### Platform Logs Platform logs offer a detailed record of all the actions and events that occur within the Kubeark Platform. These logs include a wide range of information that can be used to track and troubleshoot any issues that may arise within the platform. The Kubeark Platform uses a system of logging levels to categorize and prioritize different types of events and messages that are recorded in the application logs. These levels are used to indicate the severity of the event or message, with higher levels indicating more severe issues. The logging levels used in the Kubeark platform include: 1. **Critical**: This level is used to log events that are critical to the operation of the system and that may result in system failure or data loss if not addressed immediately. These events are considered the most severe and require immediate attention. 2. **Error**: This level is used to log events that indicate an error or problem has occurred within the system. These events may not result in immediate system failure or data loss, but they may cause issues if left unaddressed. 3. **Warning**: This level is used to log events that may indicate a potential problem or issue within the system. These events may not result in immediate system failure or data loss, but they should be monitored and addressed as needed. 4. **Info**: This level is used to log events that provide general information about the operation of the system. These events are not considered errors or warnings and are typically used to track the normal operation of the system. 5. **Debug**: This level is used to log detailed information about the system's operation that may be useful for debugging and troubleshooting issues. This level is generally intended for developers and system administrators. These logging levels are used to prioritize and filter the log events in real-time, and also for further analysis. They make it easy for users to quickly identify and address critical issues, while also providing detailed information for troubleshooting and debugging purposes. The specific elements included in the application logs may vary depending on the specific implementation of the Kubeark Platform, but typically include the following: | **Attribute** | **Description** | | ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Logger  | The logger refers to the unique identifier associated with each log event or message recorded in the application logs of the Kubeark Platform. This identity is used to identify the specific source or origin of the log event, and can be used to filter and search through the logs to find specific events. | | Level | -> Critical-> Error-> Warning-> Info-> Debug | | Message | A brief message or description of the log event. This attribute typically provides a summary of the event or action that occurred and provides context for the log event. | | Trace | A detailed trace or stack trace of the log event. This attribute provides a more in-depth view of the event, including the specific steps and actions that led to the event, which can be useful for debugging and troubleshooting. | ### Exported logs The Exported Logs page in the Kubeark Platform is designed to provide users with a comprehensive view of all the logs that have been exported from the system. This page lists all the exported logs and provides users with the ability to export new audit logs by clicking on the "Create a new exported audit log" button. Users can filter the list of exported logs by date, log type, and log level, making it easy to find the specific logs they need. They can also view the details of each exported log, including the log message, trace, username, IP address, HTTP request, and creation date. Additionally, the exported logs can be downloaded in various file formats, such as CSV, JSON, and XML, for further analysis or record-keeping. This feature allows users to keep a record of the platform's activity, troubleshoot issues, and perform compliance and auditing activities. Exported logs can be used for troubleshooting, compliance, and auditing purposes. They provide a comprehensive view of all the actions that have been performed within the platform, allowing users to track and troubleshoot any issues that may have arisen. These exported logs give users the flexibility to analyze the data in the format that suits them best. [title] Usage [path] Analytics/ ### Detailed insights into usage and spend One of the biggest issues that a SaaS company can have is the lack of visibility and predictability of their hardware / cloud consumption. Kubeark `Usage` is a powerful feature of the Kubeark platform that helps customers optimize their cloud infrastructure costs and improve profitability. By providing detailed insights into usage and spend across different Kubernetes clusters and cloud providers, Kubeark Usage enables customers to track and manage their budgets effectively and ensure that resources are being used efficiently. Kubeark usage brings numerous benefits for businesses - to name a few: - Kubeark Usage optimizes cloud infrastructure costs by providing insights into usage and spend across Kubernetes clusters and cloud providers, reducing costs and improving profitability. - It helps customers identify and eliminate inefficiencies in resource utilization, ensuring resources are used effectively. - Kubeark Usage allows for tracking and managing budgets for cloud infrastructure, avoiding unexpected costs and managing budgets effectively. - It provides detailed analytics and insights into environments for data-driven decisions on infrastructure optimization and capacity planning. - The feature enables efficient scaling of applications and services, ensuring infrastructure can handle increased traffic and demand without incurring additional costs or downtime. - Kubeark Usage reduces development costs and accelerates time-to-market for new products and services. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/2yOGTRKUVNJbeTR6wbX6U_image.png) ### Available filters - Cluster - selecting the desired cluster you wish to view - Window - the time frame which includes: *Today, Yesterday, Last month, Last 7/30/60/90 days* - Breakdown - the available options are: *Node, Namespace, Kubeark, Controller, Controller kind, Service and Pod* - Accumulation - select between a *Cumulative* or *Non-cumulative* view ### Available metrics: - `CPU hours`: This metric refers to the total amount of time that CPU resources have been used in a given period. - `CPU usage requests average:` This metric shows the average amount of CPU resources that have been requested by applications running on the Kubernetes cluster. - `CPU cores`: This metric represents the number of CPU cores that are available for use on the Kubernetes cluster. - `CPU cost`: This metric refers to the cost associated with using CPU resources, which is calculated based on the number of CPU hours used. - `CPU efficiency`: This metric measures the efficiency of CPU resource utilization, helping organizations identify and eliminate inefficiencies in their infrastructure. - `External cost`: This metric shows the cost of external resources used by the Kubernetes cluster, such as cloud storage or networking resources. - `GPU cost`: This metric refers to the cost of using GPU resources, which can be significant for organizations that require high-performance computing capabilities. [title] Creating a Workflow [path] Automation Menu/Workflows/ Here's a step-by-step guide to help you set up a workflow: ## Creating a workflow using the Workflow Editor **Step 1: Navigate to the Automation Menu** - Go to the left-side panel and look for the **Automation** section - Navigate to **Workspace** then select **Workflows** ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/nILwwo37oX1-z9avfTSKr_image.png) **Step 2: Select the Workspace** - In the top right corner of the screen, find and click on the dropdown list to select your workspace. - Once selected, a list of all existing workflows within the chosen workspace will be displayed in the working area. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/dZDpyAAuVle3qoIffYIry_image.png) **Step 3: Create a New Workflow** - Click on the **Create a Workflow** button on the top left side of the working area ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/VGAXKBLTOZrRLxHW5jcFo_image.png) **Step 4: Enter Workflow Details** - A prompt will appear for you to provide details of the workflow. - Enter the `Name`, `Description`, and `Tags` for the workflow. - Set the `Active` toggle to on or off based on whether you want the workflow to be active immediately upon creation. - Click on **Save** ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/2bfkIx_wPlXIkk8ap8svO_image.png) **Step 5: Access the Workflow Editor** - The workflow editor will then open up. Here, you will see the available nodes on the left side panel. - The central part of the screen is the active area where you'll construct your workflow. - On the top right, you'll find options for history, webhooks, and the code editor. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/rCH_c8GoB1vjbRDwCG6z3_image.png) **Step 6: Add and Configure Nodes** - Begin by clicking the plus sign on the workflow editor - A list with **top level nodes** will be displayed ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/E-pUkNyb1n_FSENIcj8Vy_image.png) :::hint{type="info"} Each node in Kubeark's Workflow Editor has its own set of customizable arguments and settings, allowing for tailored functionality within your workflow. ::: Here's an overview of the **top level nodes **and their specific customization options. | **Node Type** | **Detailed Customization Options** | | ------------------ | ---------------------------------------------------------------------------------------------------------------------- | | `Action` | Default actions can be found here [About Nodes](docId:_gz60tk0O28jqZNSBch9W) | | `Approve` | Allows you to set up a manual intervention point, where a workflow pauses until manual approval is given. | | `Workflow` | Provides a window for scripting custom logic or actions, where you can write or paste your script code. | | `Define variables` | Presents options to create and assign values to variables used within the workflow\.. | | `For Loop` | Configures loop iterations, setting how many times a particular set of actions within the workflow should be repeated. | | `Function` | Brings up a window where you can define variables, set parameters, and configure other function-specific settings. | | `Branch` | Enables you to define the conditions under which different paths of the workflow will be executed. | | `Sleep` | Allows you to set a duration for the workflow to pause before proceeding to the next step. | | `Terminate` | Involves setting the conditions under which a workflow should be prematurely ended. | | `While Loop` | Provides the ability to set a condition that keeps the workflow in a loop as long as the condition remains true. | A few examples below: ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/14RClVxIsBZHxzrihZIvy_image.png "Node arguments") ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/-oyUSVItaIBI_ZzFxnxZo_image.png) **Step 7: Test the Workflow** - Once you have added and configured the nodes, test the workflow. - Click the “Play” button located at the upper middle side of the working area. This action will execute the workflow, allowing you to verify its functionality and make any necessary adjustments. - The Execution History will pop-up, displaying the output for the recent run. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/giqiCXPm3YueRlycwJf7V_image.png) ## Creating a workflow using the Code editor For those who are more inclined towards coding or require finer control over their workflows, Kubeark offers a specialized feature: the Code Editor. This tool is ideal for creating and editing a workflow manifest directly through code. It caters to users who are comfortable with scripting and prefer a more hands-on approach to defining the intricacies of their workflows. The Code Editor provides an interface where you can write, modify, and fine-tune the workflow's underlying code, offering a high level of customization and precision. This feature is especially useful for complex workflows where specific programming logic or advanced configurations are needed. Whether you're looking to draft a new workflow from scratch or make detailed adjustments to an existing one, the Code Editor in Kubeark is a key functionality to leverage. A sample manifest can be found below: ```yaml - name: def_variables def: api_token: [add your api token] URL: [add your url] owner: owner_name owner_update: owner_update user_id: 53 - name: create_deployment_checks action: CreateDeployment input: api_token: ${{api_token}} time_out: 30 wait_for_result: false deployment: name: workflow-${{random_string(2)}} owner: ${{owner}} tags: - test template_id: 677 cluster_id: 7 default_time: 7 additional_time: 6 grace_time: 5 namespace: wftest environment_action: terminate extra_args: date: ${{ current_date() }} ingress: hostname: hello-${{ random_int(5) }}.domain.name ipTarget: 51.124.141.121 uuid: ${{ random_uuid() }} extra_args_sensitive: - uuid ``` [title] Monitoring and Analytics [path] / Kubeark offers robust monitoring and analytics capabilities to assist users in tracking application performance and identifying potential issues fast. A selection of relevant features can be found below: The `Dashboard` page under the `Analytics` menu provides insights into resource utilization, such as CPU, Memory usage and Network utilization. This data can assist users in identifying resource constraints and optimizing their applications. Administrators of the Kubeark Platform can track and manage their users with the help of a wide range of metrics and tools available in the [Users](docId\:ebDoqHVOxgkfcaOU5u9E0) dashboard. Kubeark provides a centralized and advanced logging solution for collecting, storing, and analyzing log data produced by applications and components. The [Logs (Global)](docId\:wj_E8OfITyJdk_1wkeKqR) page enables a centralized view of logs for easy searching and analysis. The below pages offer detailed monitoring and analytics: - [Dashboard](docId\:fLqxfS57_c-_Q_DbFtsEY) - [Usage](docId\:ANTSBoepVc5-5dSZ-KVhq) - [Jobs](docId\:HBkcPfQVv3j6HGcGwMUIo) - [Notifications](docId\:Gur-kAwheSvaM5VtDRQfg) - [Logs (Global)](docId\:wj_E8OfITyJdk_1wkeKqR) [title] Kubeark Identity [path] Product Guide/Organization Administration/ Kubeark IDP & SSO capabilities help customers manage their Kubeark users from within their company IDP. This allows organizations to manage user authentication and access across multiple applications and services. An Identity Provider (IDP) is a critical component of the organization's authentication and authorization infrastructure, responsible for managing and providing digital identities for its users. IDP acts as a central authority for user authentication and access management, allowing users to authenticate with a single set of credentials across multiple applications and services. This provides secure and reliable authentication services by verifying user identities and granting access based on predefined policies and permissions. IDPs also enable organizations to integrate with other external services that support standard authentication protocols, such as SAML or OAuth, further enhancing security and usability. Kubeark provides secure and reliable authentication services for its users and offers application developers and security engineers a dependable and secure solution for authentication in virtually any scenario. There are robust recovery actions available for the users and applications, including user profile and password management. You can quickly edit, deactivate, or even impersonate a user profile, and set a new password for new users or reset an existing password. Kubeark supports all of the major providers, such as OAuth2, SAML, LDAP, and SCIM, so that administrators can choose the protocol that they need for any given scenario. ### Supported protocols Kubeark supports a variety of authentication protocols, offering flexibility and integration options, through: **SAML2**, **LDAP**, **OAuth2**, **OIDC** ### Federation Support Kubeark provides support for multiple federation protocols, enabling users to authenticate and authorize access to applications and services securely. The platform supports a range of federation protocols, including **SAML2**, **LDAP**, **OAuth1**, **OAuth2**, and **OIDC**. These protocols provide a standardized and secure way for users to authenticate and access resources across different environments and applications. With support for these protocols, Kubeark offers flexibility and integration options, allowing users to use their preferred identity provider for authentication and access control. ### Multi-Factor authentication The platform provides support for **multi-factor authentication (MFA)**, which adds an extra layer of security to user accounts by requiring additional authentication factors beyond just a username and password. This feature significantly reduces the risk of unauthorized access to applications and resources. Kubeark also supports **conditional access policies**, which allow administrators to define specific conditions for accessing resources, such as location, device, and user group, among others. These policies ensure that only authorized users are allowed to access resources and help prevent unauthorized access attempts. Additionally, Kubeark offers **application proxy capabilities** that enable secure remote access to applications and resources. This feature provides a secure gateway that acts as an intermediary between the client and server, allowing users to access their applications and resources from anywhere, while ensuring that traffic is securely encrypted and authenticated. [title] Notifications [path] Architecture/Platform Interface/ An essential part of the Kubeark system that provides users real-time updates and notifications is the Notifications page. The page lists all recent alerts that the system has created and offers key details about each notification. The Notifications page displays a list of recent system notifications that include information such as the server time, cluster name, namespace, kind of object, name of object, message, and type of notification. This is an essential tool for monitoring and managing the Kubeark system due to its concise display of notifications, which allows users to quickly identify and respond to any issues. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/062mwykJZ6-GGhwgwTsIR_notifications-2.png) A notification consists of the following parameters: 1. `Server time`: This is the current time according to the server's clock. 2. `Cluster name`: The name of the cluster to which the notification belongs. 3. `Namespace`: The namespace in which the notification was generated. 4. `Kind`: The type of object that generated the notification (e.g. Deployment, Pod, etc.). 5. `Name`: The name of the object that generated the notification. 6. `Message`: A brief description of the notification. 7. `Type`: The type of notification, such as an error, warning, or informational message. The Notifications page provides a comprehensive overview of all Kubeark system notifications. The user can quickly determine the source of the notification, the type of notification, and any relevant information. The notifications can also be filtered by `kind`, `type`, `cluster` `name`, and `namespace`. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/ZmNVfHA-ftoYSYR4Y-Wds_image.png) [title] Bulk Update Deployments [path] How to's/ Kubeark is an enterprise-grade platform designed to simplify container and application management for organizations of all sizes. One of its unique characteristics is the capability to execute bulk update deployments on clusters, enabling quick and easy system changes. This means that organizations can quickly and easily roll out updates to their applications, ensuring that all users have access to the latest and most secure features. With Kubeark, managing large-scale container deployments has never been easier. Continuing our exploration of Kubeark's features, let’s see in detail how this works. ### Step-by-step guide for Bulk Update Deployments :::::WorkflowBlock :::WorkflowBlockItem To begin, go to the `Template Management` menu on the left-hand side of your platform interface and select `Groups` ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/QbzOnybylaBpSaPS1Vno__bulk-1.png" signedSrc size="58" width="512" height="348" position="center" caption} ::: :::WorkflowBlockItem Select your group from the list of existing groups and here you will see the Templates list. Then, select your desired template from the list of templates. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/A9wZ_h9zhMzRxxIEuGxjB_bulk-2.png) ::: :::WorkflowBlockItem On the upper right side of the screen, an option named `Create Version` will be visible. Here you will also find a list of **all available versions** linked to this main template, if any have been previously created. ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/N8R-Rjsggl6qcwoX_WyJ4_bulk-3.png" signedSrc size="58" width="330" height="680" position="center" caption} ::: ::::WorkflowBlockItem Select the template version that you want to modify. We will call this the “target” version going forward. :::hint{type="info"} Please note that bulk update deployments can be performed on active template versions only. These are easy to identify by checking the blue dot icon associated with the version name ::: :::: :::WorkflowBlockItem Once you have selected the target version, click on `Upgrade deployments` ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/0qLQ1GNum41DYOCuZEIbj_bulk-4.png) ::: ::::WorkflowBlockItem Here you will see a list of all available deployments. Select the deployments you want to migrate by using the checkboxes on the left-side of the list. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/x-1ZyL4h1l00CKTcLM6_5_bulk-5.png) :::hint{type="info"} The list will only show deployments available in other template versions, for migration purposes. The ones that are already associated with your target version will not be displayed. Kubeark allows for multiple deployments to be selected, including deployments associated with different versions ::: :::: :::WorkflowBlockItem Upon selecting the deployments you want to upgrade, click on `Upgrade [#] deployments` ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/bizx9V2LutMtIkU7HcwVK_bulk-6.png) ::: ::::WorkflowBlockItem After selecting the desired option, a new page will be displayed, providing you with the ability to add and configure the necessary parameters for your updated template. When configuring the parameters for your updated template, Kubeark offers flexibility as follows: - **Option 1: **select from a list of pre-existing parameters that are available in your target template - **Option 2: **define your own custom parameters, tailored to meet the specific requirements of your updated template - **Option 3**: use a combination of pre-existing parameters and newly defined custom parameters. :::hint{type="info"} If there are no changes to your parameters, you also have the option to leave the existing parameters intact. ::: :::: :::WorkflowBlockItem Once you have added the required parameters, click `Update` ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/skPEAO7d08OixF_hV7rU7_bulk-7.png) ::: ::::: ### Verify the successful Update process :::::WorkflowBlock :::WorkflowBlockItem After completing the previously mentioned steps and updating your deployments, it is important to validate the success of this operation. To do so, navigate to the **Analytics** tab in the main platform menu and select **Jobs** ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/odLG1Y3NVSoFRcL3Ar79L_bulk-8.png" signedSrc size="56" width="526" height="634" position="center" caption} ::: ::::WorkflowBlockItem Within this section, you will be able to review the status of the update process and ensure that all changes have been applied successfully. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/s0kBZ34jg2ZA4RC2b2D4n_bulk-9.png) :::hint{type="success"} Upon the completion of the update process, as indicated on the Jobs page, all your deployments will have been successfully updated. ::: :::: ::::: [title] Policies [path] Product Guide/Organization Administration/Untitled/ Policies are an important component of Kubeark Identity, allowing you to define the rules and procedures that govern how the users can interact with the platform, including authentication and enrollment flows, user attributes and others. ## Event-matcher policy This policy is used by the events subsystem. You can use this policy to match events by multiple different criteria, to choose when you get notified. ## Expression Policy This evaluates an expression or a set of expressions to determine if the policy should be allowed or denied. These expressions can reference context data, which includes data about the user, device, and other relevant information. Expression policies allow for greater flexibility and customization in managing access and permissions. The passing of the policy is determined by the return value of the code. Use ```text return True ``` to pass a policy and ```text return False ``` to fail it. Available functions: **ak\_message (message: str) **- Add a message, visible by the end user. This can be used to show the reason why they were denied Example: ```yaml ak_message("Access denied") return False ``` **regex\_match(value: Any, regex: str) -> bool **- check if value matches Regular Expression  Example: ```yaml return regex_match(request.user.username, '.*admin.*') ``` ## Password-Expiry Policy This policy aims to ensure that users change their passwords regularly by setting an expiration period for passwords. When a password has reached the specified time limit, the policy expires the password, and the user is required to set a new password. This helps enhance the security of the system by reducing the risk of password breaches or attacks. ## Password Policy This policy allows you to specify password rules, such as length and required characters. The following rules can be set: - Minimum amount of uppercase characters. - Minimum amount of lowercase characters. - Minimum amount of symbols characters. - Minimum length. - Symbol charset (define which characters are counted as symbols). ## Reputation Policy This policy describes the ability to track failed login attempts based on the source IP and attempted username. The policy stores these values as scores, where each failed login attempt results in a decrease of the client IP and targeted username scores by one. This policy can be used, for example, to prompt clients with a low score to pass a captcha before they can continue. To make sure this policy is executed correctly, set `Re-evaluate policies` when using it with a flow\\ [title] User Delete/Login/Logout stage [path] Product Guide/Organization Administration/Untitled/Untitled/ ## User Delete This stage is designed to be used in a flow that removes a user from the system, and it deletes the user who is currently in the pending state. Additionally, the user is removed from the current session. ## User Login The purpose of this stage is to attach a `pending user` to the current session. It can be utilized during an enrollment flow after `user_write`, or during an authentication flow after a `password` stage. ::::Tabs :::Tab{title="Session duration"} By default, the session is set to expire when you close your browser. This can be customized so that you can set the session to expire after any duration using the syntax of `hours=1,minutes=2,seconds=3` The following keys are accepted: *Microseconds, Miliseconds, Seconds, Minutes, Hours, Days, Weeks.* ::: :::Tab{title="Stay signed in offset"} When this is set to a higher value than the default *seconds=0*, a prompt is shown, allowing the users to choose if their session should be extended or not. The same syntax as for *Session duration* applies. ::: :::Tab{title="Terminate other sessions"} When enabled, previous sessions of the user logging in will be revoked. This has no affect on OAuth refresh tokens ::: :::: ### User Logout The stage is the opposite of **User Login** Stages, which means that it logs out the user by removing them from the current session. [title] Audit menu [path] / [title] Clusters [path] Cluster Management/ ## Overview A cluster is a collection of autonomous environments that can each execute its own workloads and applications. A cluster typically has its own set of resources, including virtual computers, storage, and a network, enabling the creation of distinct environments that can function independently. The Kubeark platform requires the use of a Kubernetes cluster as the fundamental unit of organisation. The platform's scalability and flexibility can be improved by adding clusters. As the number of clusters included in a license dictates the price and level of functionality of the platform, they are a key component of the licensing model. The Kubernetes `cluster` is a collection of physical or virtual machines that are connected and operate together to run containerized applications. The Kubeark Platform was designed to support multiple Kubernetes clusters by remotely connecting via an API Kubernetes server and allowing for the execution of CRUD (`Create`, `Read`, `Update`, and `Delete`) operations via the Kubeark platform. Kubeark's multi-clustering functionality is achieved through the use of contexts, which represent a configuration that defines the `cluster`, `user`, and the `API` server's credentials for the specified cluster. The context allows the platform to communicate and perform operations on the specified cluster. :::hint{type="info"} The number of active clusters that a license includes is one of the key factors that determine the cost of the license, and the usage of clusters is subject to the terms and limitations of the license. ::: ## Managing clusters in Kubeark The Kubeark platform offers a centralized management system for clusters, which allows you to perform various tasks such as adding and editing your clusters on the Clusters page. This page provides a user-friendly interface that allows you to easily manage your clusters. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/VPZpMEse9Th6iQV7NPsFx_image.png) ### Create and Upload The following attributes are available when creating a cluster: - [ ] `Cluster Name` - the desired name of the new cluster - [ ] `Status` - the status toggle can be set to Active or Disabled - [ ] `Prometheus URL`- specify the URL of the Prometheus server used to monitor the Kubernetes cluster. Prometheus is an open-source monitoring and alerting tool that is commonly used to monitor Kubernetes clusters. - [ ] `Usage Service UR`L - specify the URL of the usage service used to track the usage of resources within the Kubernetes cluster - [ ] `Details` - additional information about the Kubernetes cluster, such as the number of nodes, pods, and services in the cluster - [ ] `Description` - an optional field that allows you to enter a description or notes about the cluster - [ ] `Cluster Config` - the option for uploading a custom configuration file (supported formats are `.json` and `.yaml`) - [ ] `API Config` - this category requires the necessary information to connect to the Kubernetes API server for a specific cluster, and includes the following editable fields: ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/_sVFDwgRbf9Orolf5L-KR_clusters-2.png) The Kubeark Platform also offers a drag-and-drop functionality for uploading your Cluster Configuration (we will call this `kubeconfig`), represented by the `YAML` or `JSON` file. This feature allows you to easily and quickly upload your existing clusters to the platform, without the need for manual configuration or command line interface. Simply drag and drop your Cluster Config file onto the designated area of the Clusters page and the platform will handle the rest, allowing you to focus on managing and scaling your clusters. ### Validate connection Kubeark provides the means to verify that the `cluster` can be reached by the Kubeark platform services, validating your credentials and the network status. ### Cluster monitoring After setting the attributes on the Cluster page, the next step in monitoring your clusters is to provide a `Prometheus URL`. This URL consists of four parts: - *the Prometheus service name* - *the namespace* - *the security protocol* - *the port number.* The URL should be in the format of "`prometheus-service.namespace.svc:port`". For example, the Prometheus URL for a service named "prometheus-service" within the "monitoring" namespace and using the "http" protocol on port "8080" would be: "`prometheus-service.monitoring.svc:8080`". This URL is used to connect to the Prometheus server, which is responsible for collecting and analyzing metrics from your clusters, and providing real-time visibility into the performance and resource usage of your clusters. With this URL you can monitor and analyze your clusters to help detect potential issues and optimize performance, as well as build visualizations and alerts to notify you of any critical events happening in your clusters. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/jWahDwp3hz89Pqk6asvc4_clusters-3.png) [title] Organization Administration [path] Product Guide/ ### Control access, customize roles, and secure your resources with the Kubeark Platform Kubeark offers a complex and customizable access control system, in which permission types grant authorized users access to specific sections of the web application. These permissions include the ability to read, create, update or delete items within the designated section or page. Furthermore, roles are established as a grouping of these permissions, assigned under a specific name. These roles can be tailored to the client's needs and preferences, as the permissions that compose each role are predefined within the backend of the application. The advanced Role-Based Access Control (RBAC) system will enable you to establish granular permission levels based on your own security principles. This allows you to create and manage complex access control rules to protect your resources and ensure that only authorized users have access to sensitive data and functionality. These capabilities can be accessed through the **User Management** menu. Here you will find the respective sections for managing `Users` and `Roles`. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/3GkHvo_UhrNCNGcsAyaz2_image.png) [title] Platform Menu [path] Architecture/Platform Interface/ The Platform Menu is an integral component of the Kubeark Platform, offering users a seamless navigation experience throughout the interface. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/UsiUfKl6tiZzNg8eX05uS_image.png) In the Platform Menu, you will find various sections such as: - **Collapse/Expand:** This toggle interacts with the Features menu. By reducing the size of the `Features Menu`, you will get more space for the `Working Area`. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/yTxO7yz7HDXvgyfRCVF6p_minimizemaximize.png) - **Notifications**: This menu helps you to identify all the actions performed as events in Notifications list. Detailed information about Kubeark notifications can be found [Notifications](docId\:Gur-kAwheSvaM5VtDRQfg). ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/Bn19VIGELRQS_b_fKWXQF_notifications.png) - **My Profile**: By selecting your initials from the top right corner you will have access to the `My Profile` page, where you can modify `Basic Info``,` `User Preferences` and `User Roles` ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/vyTi0P8Zfr6N10bqtil4t_logout.png) ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/QbVk7fc5zawgcYkRMXGI5_logout2.png" signedSrc size="54" width="556" height="574" position="center" caption} - ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/13x3k1SoB69Zf9m16lmam_image.png) ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/uWKIbcKKuhY0OZUH_iDtB_image.png) [title] Forms [path] Automation Menu/ sIn the domain of automated processes, the initiation and successful execution of workflows frequently depends on the accurate acquisition of user-provided information or specific details. Addressing this requirement, Kubeark Forms emerges as a dynamic and versatile tool, crafted to facilitate the efficient collection of essential data required for commencing automation workflows. This functionality extends beyond mere information aggregation; it embodies a sophisticated, user-focused approach, tailored to accommodate a diverse array of requirements and scenarios. By integrating adaptability and user-centric design, Kubeark Forms ensures accurate and relevant data collection. The `Forms` menu can be found under the `Automation` section of the main feature bar. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/mZsuz00g3ruA6etbPYB4w_image.png) ## Key features of Kubeark Forms 1. **Customizable Data Collection**: - Design forms tailored to gather the exact information needed for various automation processes. - Customize fields to ensure that all essential data points are captured accurately and efficiently. 2. **Adaptive Logic in Forms**: - Implement conditional logic within forms to create a responsive user experience. - For instance, if a customer opts for a virtual machine, the form will present fields relevant to that choice. Conversely, selecting a database will prompt a different set of input fields. This adaptive logic ensures users provide only the relevant information based on their specific needs. 3. **Public Accessibility**: - Forms can be configured to be public, allowing them to be accessed and filled out by users outside of the Kubeark platform. - This feature significantly expands the utility of forms, enabling data collection from a wider audience and various stakeholders. 4. **Automation Triggers**: - Forms are not just for data collection; they can act as triggers for automation processes within Kubeark. - Once a form is submitted with the required information, it can automatically initiate predefined workflows, making the transition from data collection to action seamless and efficient. ## How to use Forms To access the Form designer, go to the `Automation` section > Forms and Select "**Create a Form"** ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/5YQfvOk7Twoh8wqtAXgqM_image.png) ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/eU875jRpecgnDhjKgwyaO_image.png) The Forms feature in Kubeark is divided into multiple tabs, each serving a specific purpose in the form creation and configuration process. Below is a description of each tab: **1. Designer Tab**: - This is where you design your form using various elements like radio buttons, checkboxes, dropdowns, etc., as described in the previous tabular view. - It provides a user-friendly interface for adding and arranging form fields, customizing the layout, and setting properties for each element. - On the "**Designer**" tab you will find a set of predefined snippets to choose from in order to build your form: | **Option** | **Description** | | ------------------------ | ------------------------------------------------------------------------------------------------------------------ | | `Radio Button Group` | Allows users to select one option from a predefined set of mutually exclusive choices. | | `Rating Scale` | Enables the collection of responses by allowing users to rate a statement or item on a numerical scale. | | `Checkboxes` | Provides a list of items from which users can select multiple options. | | `Dropdown` | Presents a dropdown menu with a list of options, allowing users to select one. | | `Multi-Select Dropdown` | Similar to Dropdown, but allows users to select multiple options from the dropdown list. | | `Yes/No (Boolean)` | Offers a simple yes/no choice, ideal for binary decisions or confirmations. | | `File Upload` | Allows users to upload files as part of their form submission. | | `Image Picker` | Enables users to select an image from a set of provided options. | | `Ranking` | Lets users order options or items according to their preference or importance. | | `Single-Line Input` | Provides a field for short text input, typically used for single-line responses like names or email addresses. | | `Long Text` | Offers a larger text box for longer responses, suitable for detailed feedback or descriptions. | | `Multiple Textboxes` | Presents several text boxes in one question, each for collecting different pieces of related information. | | `Panel` | A container that can group related items or questions together, enhancing form organization. | | `Dynamic Panel` | A more flexible version of the Panel, which can change based on user input or conditions set in the form. | | `Single-Select Matrix` | Displays a grid of questions (rows) and options (columns), allowing users to select one option per question. | | `Multi-Select Matrix` | Similar to the Single-Select Matrix, but allows users to select multiple options for each question in the grid. | | `Dynamic Matrix` | A matrix that can adapt or expand based on user responses, adding rows or altering options dynamically. | | `HTML` | Enables the inclusion of custom HTML content for enhanced formatting or displaying additional information. | | `Expression (Read-Only)` | Displays read-only content that can be dynamically changed based on formulas or user inputs elsewhere in the form. | | `Image` | Allows the insertion of images into the form for visual reference or enhancement. | | `Signature` | Provides a space for users to add a digital signature, often used for consent or verification. | | `Date Time Picker` | A tool for users to easily select dates and times, useful for appointments, reservations, or logging events. | **2. Preview Tab**: - Offers a live preview of the form as it's being designed. - It allows you to see how the form will appear to end-users, helping to ensure that the layout and flow are user-friendly and intuitive. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/V-1ijL5mP_pOaIn5-KzSB_image.png) **3. Logic Tab**: - Enables the addition of conditional logic rules to the form. - You can create rules based on user responses to previous questions (e.g., if a certain answer is given, then show or hide a particular field). - This tab allows for the configuration of complex form behaviors, making the form dynamic and interactive based on user inputs. - ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/uWBpHJW-WkQyK6qYSaYYS_image.png) **4. JSON Editor Tab**: - Provides a view of the form's configuration in JSON format. - This is useful for advanced users who prefer to work directly with code or need to make bulk changes quickly. - It allows for a more technical and detailed customization of the form, beyond what is possible through the graphical interface. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/9m_vi4W2GGZai6fJcsode_image.png) **5. Triggers Tab**: - This tab lets you link your form to various functions and workflows. - The 'Add Functions' option includes predefined functions that can be triggered based on form submissions. - The 'Add Workflows' option allows you to integrate the form with specific workflows. You can select a workspace and then choose the desired workflow to be triggered when the form is submitted. This functionality enables the automation of processes and workflows based on the data collected through the form. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/vBacFf73k9NibZeLpQhYP_image.png) [title] Support Terms [path] Lifecycle/ At Kubeark, we prioritize providing exceptional support to our valued customers. This page serves as a guide to understand the terms and policies surrounding our support services. We are committed to ensuring your success and satisfaction by offering timely assistance, clear communication, and effective resolutions to any technical issues or inquiries you may encounter. By familiarizing yourself with our support terms and policy, you will gain insights into our service levels, response times, escalation procedures, and other crucial aspects that define our commitment to delivering outstanding support. Detailed information can be found in our Support Policy. [title] Hardware Requirements [path] Getting Started/Prerequisites/ The hardware requirements section outlines the necessary hardware configurations for successful deployment and operation of Kubeark. This includes information on recommended and minimum memory, storage, and processing power needed for optimal performance. :::hint{type="info"} It is important to review and confirm that your system meets these requirements before proceeding with the installation and setup of our product. ::: The following are the minimum recommended hardware specifications that must be met in order to ensure proper functioning of our product on each node: ### Minimum resource requirements | **CPU** | **RAM** | **HDD** | | ------- | ------- | ------------------------- | | 2  | 8 GB | Secondary raw disk - 40GB | ### Recommended resource requirements - aks/eks - min 2 nodes with 4 CPU, 16 GiB & premium storage - hw/vm/vSphere - 3 nodes with 4 CPU, 16 GiB & 80GB ssd | **CPU** | **RAM** | **HDD** | | ------- | ------- | -------------------------- | | 4 | 16 GB | Secondary raw disk - 100GB | [title] Untitled [path] Automation Menu/ [title] Workspaces (Settings) [path] Settings Management / The Workspace settings menu, located within the main Settings section of Kubeark, provides a comprehensive view and control panel for all available Workspaces. This area is useful for administrators to effectively manage the various Workspaces within the platform. Upon accessing the Workspace Settings, users are presented with a list of all existing Workspaces. This list offers an at-a-glance view of each Workspace, including relevant details that aid in quick identification and selection. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/5oif2TzQVZwXSU-Spbfiz_image.png) ## Workspace Management Options The user interface is designed for ease of use and clarity. Each Workspace in the list is accompanied by intuitive icons and options for editing or deletion. Clear prompts and confirmations are provided to ensure users are aware of the implications of their actions, particularly in the case of deleting a Workspace. ### **Creating a new Workspace** Users have the option to create new Workspaces. This function is essential for starting new projects or organizing resources for different teams or purposes. The creation process involves specifying details such as the Workspace name, description, and configuring relevant settings and permissions. **Step 1:** Go to the Settings Management sections within the main features menu and select Workspaces **Step 2:** Add the necessary arguments such as workspace name, description and tags **Step 3:** Click on Save ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/FHRFoWvfveKoYIdR4SfUi_image.png) ### Mark as Favourite By marking a Workspace as a favourite, users can quickly access their most frequently used or important Workspaces. This feature is particularly beneficial in environments where numerous Workspaces exist, as it helps in prioritizing and organizing them more efficiently. Favourite Workspaces are typically highlighted or listed at the top of the Workspace menu, allowing for swift navigation and reduced search time. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/9KuLerNdpCEDg4Hun-34p_image.png) ### **Edit a Workspace** Existing Workspaces can be modified to reflect changes in project scope, team structure, or other requirements. The edit option allows users to update Workspace details such as name, description or tags, ensuring that each Workspace remains aligned with its intended purpose and current needs. It comprises two main tabs: `Workspace Details `and `Permissions` each serving a specific purpose in Workspace customization and security. The `Workspace details`** **tab** **facilitates the following actions: - **Edit Workspace Name:** Users can update the name of the Workspace to reflect the current focus or project scope. - **Modify Workspace Description:** The description field can be edited to provide more context or updated information about the Workspace. - **Manage Tags:** Users have the option to add, remove, or modify tags associated with the Workspace. Tags are instrumental in categorizing and locating Workspaces, especially in environments with multiple Workspaces. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/o5Hm3HP0rZ2z4Z2kgmPDE_image.png) The `Permissions` tab enables the following actions: - **Add User Role:** This function allows administrators to assign roles to users within the Workspace. Roles are crucial for defining the level of access and control a user has. - **Add a User**: Administrators can invite new users to the Workspace, enhancing collaboration and resource sharing. - **Edit Permissions**: Permissions for each user can be tailored based on a CRUD (Create, Read, Update, Delete) logic. This ensures precise control over who can access and modify various aspects of the Workspace, enhancing security and operational efficiency. - **Delete user**: This functionality allows administrators to remove a user's access to the Workspace entirely. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/9hR2xl7LPolZBvJF_dqAZ_image.png) ### **Delete a Workspace** When a Workspace is no longer needed, it can be safely removed from the system. This option should be used with caution, as it involves permanently deleting the Workspace and potentially all associated resources and configurations. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/_56YNJtYokD4P5y7j38pU_image.png) [title] Artifacts [path] Environments Menu/ ## Overview Navigating the complexities of infrastructure management often presents a daunting challenge: setting up the essential infrastructure components is time-consuming. In response, we developed Artifacts, a carefully selected collection of reusable parts, along with pre-configured modules to speed up deployment. Artifacts also provides a predefined template library, giving our clients the freedom to select and integrate only the components that meet their infrastructure requirements. Artifacts is your one-stop repository for Kubernetes templates, boasting a collection of **over 130 ready-to-use configurations**. Whether you're aiming to deploy CRMs, CMSs, databases, or a multitude of other products, Kube Artifacts offers a rich selection tailored for diverse business needs. Moreover, its flexible design allows organizations to handpick and make available specific templates that best fit their operational requirements, ensuring a tailored experience for every Kubeark user. Designed with the needs of modern enterprise in mind, Kube Artifacts contains the most frequently utilized services and databases, ensuring that the right teams can effortlessly deploy and manage the most in-demand services with ease. :::hint{type="info"} KubeArtifacts is a collection of reusable components and predefined template library ::: ## Step-by-step guide **Step 1 - Access the Main Platform Menu**: Begin by navigating to the primary interface of the Kubeark platform. **Step 2 - Locate 'Environments'**: Within the main platform menu, look for *Environments* **Step 3 - Select 'KubeArtifacts'**: Under the 'Environments' dropdown or section, you'll find an option labeled `KubeArtifacts`.  ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/IBHQSf1uq364z5vhB_b1e_image.png) **Step 4 - Explore the Template Collection with Enhanced Search:** Once inside KubeArtifacts, you'll be greeted by an extensive collection of over 130 predefined templates. Each of these templates is tailored to address common infrastructure scenarios, enabling your setup processes. :::hint{type="success"} On the KubeArtifacts page, you'll notice a search function at the top. This feature allows you to quickly find templates based on keywords, category, version, or other criteria, ensuring you pinpoint the right template without any hassle ::: **Step 5 - Choose Your Desired Artifact:** Browse through the available templates, find the one that best aligns with your current requirements, and select it. Each template comes with a brief description to aid in your decision-making. Each artifact is presented in a structured card format, containing relevant details including its description, category, associated version, and licensing information. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/LrUydX3vrg7K_I0b4HqEO_artifacts2.png) The card can be expanded to show detailed infromation about the respective artifact. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/7iFaP5j7OwGVV2y8IZ5i1_image.png) **Step 6 - Deploy Your Selected Template**: Once you've selected an artifact, on the bottom of the page you will find the `Import artifact` option. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/gPdIhsL18D5JbsmlLh6kK_image.png) **Step 7 - Edit template: **The next page will take you to the template details where you can customize the artifact deployment with your desired parameters such as name, template group, cluster group etc. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/QZ5z7_nZmTdPsRmg74-Z1_image.png) **Step 8 - Create your deployment based on the selected artifact** ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/iDTVTI82YdSHootpDQfkx_artifact-create-depl.png) [title] Working with Templates: Update/Rollback/Delete [path] How to's/ Kubeark provides a highly adaptable approach to managing templates, which includes user-friendly methods for modifying, rolling back, or removing a template. This allows for easy template maintenance, facilitating the development and management of applications with greater efficiency and precision. We have learned how to setup our template groups and how to create template versions in just a few simple steps. Let’s see how we can update a deployment with a specific template version. There are two ways of updating a deployment: - Deployment level updates - Template level updates *** ### Option 1: Updating at the Deployment level - Go to `Template Management` and select `Deployments` - a list of all available deployments will display - ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/BqulK1wib6IgAnuci3QXI_mg-tmpl-1.png) - Select the deployment you wish to modify by clicking the corresponding line item - From the deployment details page, select `Update` and here you will see a list of all available template versions - The `Actions` column shows the active template version on the respective line item. - ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/_9nF0v8Apka9NBok9zb5P_mg-tmpl-2.png) - From here, click on `Update` in order to activate a different template version - A new template page will open, allowing you to review and edit the desired parameters. Kubeark allows you to select your parameters (*ipTarget, ingress, deployed\_by, deployment\_uuid, public*) either **from template**, either **from current deployment.** - ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/u4pxwfapMu61KqacNCiUN_mg-tmpl-3.png) - Once you have finalized configuring the parameters, click on **Update** :::hint{type="success"} The same procedure can be applied in **rollback** scenarios by selecting a previous template version ::: ### Option 2: Updating at the Template level - Go to `Template Management` and select `Groups`, choose your desired template group - Within the group, select your desired `Template` - On the right side of the screen you will see the available template versions. The active versions are marked with a blue dot, as shown in the below picture. - Select your desired Template version from the list and click on `Upgrade deployment` ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/Dg-YTWWVLNEAaSgfkvU8G_mg-tmpl-4.png) :::hint{type="success"} The same procedure can be applied in **rollback** scenarios by selecting a previous template version ::: ### How to Delete a Template - Go to `Template Management` > `Groups` and select your desired template group from the list - The list of available templates is displayed on the screen - The `Actions` column on the right of the screen displays the available actions such as: `Edit`, `Duplicate` or `Delete` - For deleting a template, select the Bin icon ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/czrGKMdmWo-Jq4dSJxD5l_mg-tmpl-5.png) [title] Deployment Options [path] Architecture/ Kubeark provides a variety of deployment options, ensuring flexibility and catering to the diverse needs of our customers. ::::ExpandableHeading # On-premises/Private/Public Cloud (Customer Managed) Customers have the option to choose the **on-premises deployment model**, where they can run Kubeark on either physical or virtual machines within their hardware and infrastructure. This can be done in their own data center or on their premises. This model is especially beneficial for organizations that require complete control over their infrastructure and data, including those operating in areas with limited internet connectivity, or running an airgapped, regulated environment. Alternatively, you can also opt for a **private or public cloud hosting such as MS Azure **(customer managed service). This allows customers to have more control over their deployment while still having the flexibility to choose the hosting option that suits their needs. :::hint{type="info"} **On-premises:** run Kubeark on either physical or virtual machines within your environment **Private/Public Cloud: **use a preferred cloud service (e.g. AWS) ::: :::: ::::ExpandableHeading # Kubeark hosted\* In this model, KubeArk manages the entire infrastructure and software stack, and customers access Kubeark's services through the cloud :::hint{type="warning"} *\*Note: this option is on the roadmap* ::: :::: [title] Deny stage [path] Product Guide/Organization Administration/Untitled/Untitled/ To conditionally prevent users from accessing a flow, this stage halts the flow's execution. This can be done even if users are not signed in, and permissions cannot be verified via groups. [title] Infrastructure [path] Environments Menu/ **Welcome to Kubeark's Infrastructure section. Here you will find straightforward templates to help you define, provision and manage your infrastructure resources.** *** The Kubeark Infrastructure feature is designed to cater to the growing demand for a streamlined, centralized, and user-centric approach to handle provider data within Terraform templates. Recognizing the challenges faced during the configuration of provider-specific details —be it authentication credentials or unique feature customizations— the Kubeark Infrastructure module emerges as a mean of simplification. At its heart, this module offers a centralized repository where all provider data is securely stored and managed. This allows users to effortlessly select and configure their desired provider without getting entangled in intricate setup processes. Kubeark aligns with Terraform plans, whether it's deploying virtual machines, procuring PaaS solutions like SQL PaaS from cloud providers, or even orchestrating a Kubernetes cluster. Once a Kubernetes cluster is established via Terraform, it seamlessly links to Kubeark, facilitating the deployment of K8s templates within it. ## About the module The Infrastructure menu is located under the Environments section of the Kubeark platform. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/xu-NwDr4AwpMLstN9nQX4_infra-main.png) ### The Templates menu Within the Infrastructure section, the "Templates" component represents pre-defined configurations tailored for use with Terraform. These templates act as foundational scripts or blueprints, guiding users through the process of defining, provisioning, and managing various infrastructure resources. By leveraging these Infrastructure Templates, users can ensure that their infrastructure components—ranging from virtual machines and networks to storage solutions—are set up in a consistent, efficient, and technically accurate manner. The objective is to provide a reliable starting point, reducing the overhead of creating configurations from scratch and ensuring alignment with industry best practices. ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/Mrye4LvrzMx7Z-0ojpJT6_image.png" signedSrc size="56" width="242" height="65" position="center" caption} ### The Deployments menu The "Deployments" component in the Infrastructure section stands as the practical application of the Infrastructure Templates. It is here that the predefined templates are brought to life, initiating the actual process of provisioning and configuring the infrastructure resources as per the guidelines set in the templates. Deployments ensure that the resources are instantiated consistently, based on the parameters and configurations specified within the chosen template. In essence, while the Templates provide the blueprint, the Deployments actualize them, translating the theoretical configurations into real-world, operational infrastructure components. ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/z2EbYcxV4Db9JVMvIksmY_image.png" signedSrc size="56" width="230" height="64" position="center" caption} [title] Automation Menu [path] / [title] Global Vault [path] Settings Management / ## Overview The Global Vault offers a centralized repository for managing certain values that are used across multiple components like database credentials, API keys, and environment-specific settings. This ensures that every component of an application references a singular, consistent source for its configurations. Vault centralizes and manages configuration values that are essential for various components of your application. By simplifying the process of defining, scoping, accessing, and managing these variables, Vault enhances the overall efficiency and security of your deployments. This platform ensures a reliable and streamlined approach to handling configuration values, promoting consistency and reducing maintenance efforts. :::hint{type="warning"} The Global Administrator in the Kubeark platform, will have the ability to view all variables stored within the Global Vault as well as the Workspace Vaults (Local Vaults) ::: ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/g3h2IvTXLPd5YTc927Zuo_image.png) ## Capabilities The Vault feature in Kubeark, accessible via the Settings Management menu, offers a robust list of platform-specific variables and configurations. Within the main Vault page, users are presented with a main menu organized into multiple tabs, each dedicated to a distinct aspect of the platform. These tabs include Cluster Management, Infrastructure (Infra), Jira, Sources, Template Group, Workspace, User, Function, and Workflows. - **Cluster**: Vault's cluster management section provides users the tools to define, edit, and oversee variables associated with different clusters. Ensure each cluster operates with its designated configurations and accesses the correct resources. - **Infra: **This is where users manage the variables related to infrastructure setups. Whether you're working on networking configurations or storage parameters, the 'Infra' section makes it straightforward. - **Jira**: The Jira tab in Vault is dedicated to managing variables specifically related to Jira integrations. It allows users to configure and maintain settings that ensure seamless connection and interaction with Jira systems. This could include API keys, project IDs, or other data necessary for integrating and automating tasks between Kubeark and Jira. - **Sources**: In the Sources tab, admins can manage variables associated with various source control or 3rd party systems. - **Template Group:** Organize and manage variables related to different template groups. Tailor configurations to cater to specific template group needs, ensuring optimal deployment and functioning. - **Workspace: **The Workspace section within Vault focuses on managing variables that are specific to individual Workspaces - **User**: Personalize user experiences or manage user-specific data by employing the user variables section. This feature ensures individual users or groups operate under their specific parameters. - **Function:** Integrate and manage specific function-related variables with ease. Whether it's a custom function or a predefined one, ensure it has the right settings to execute correctly. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/CJ9HTgnMrcGKOr-fT5P9G_image.png) ## How to create a Vault key? **Step 1 - Access the Vault**: navigate to the Settings menu in the main application dashboard **Step 2 - Initiate Key Creation: **once inside the Vault section, select `Create Key` ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/qcj23p1uma9NVPz4ILkWE_image.png) **Step 3 - Fill in the Key details: **Upon selecting Create Key, a prompt will open, allowing you to enter the desired arguments for the key creation ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/jscgO10N-QnkND5_sTJHj_vault4.png) | **Argument** | **Description** | | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Name` | Enter the desired name for your key. This will be how you reference it in future | | `Value` | Input the actual data or value for your key. This can be any string of text or numbers. | | `Is Secret?` | You will see a toggle switch labeled "Yes/No". If your key contains sensitive information that should be hidden or encrypted, toggle this to "Yes".  | | `Description` | Provide a brief description of the key. This can be helpful for others who may use this key, or for you to recall its purpose later. | | `Scope` | Here, you can define the scope of the key's applicability. Choose from the following options based on where you want this key to be used:
`-> Cluster`
`-> Infra`
`-> Jira`
`-> Sources`
`-> Template Group`
`-> Workspace`
`-> User`
`-> Function` | **Step 4 - Save & Confirm:**Once you have filled in all the required arguments, click on `Save` Now, you have successfully created a key within Vault. This key will be available for use as per the scope you've defined, ensuring a consistent and efficient configuration process.   [title] Jobs [path] Analytics/ The Jobs page is a key feature of Kubeark's monitoring capabilities, providing valuable insights into job performance and progress. This page offers a comprehensive view of all jobs, displaying information based on key attributes such as ID, Status, Name, Progress bar, Action Type, Scheduled Date, Started at, Created by, and View job. The `Jobs` page can be found under the **Analytics** menu on the features sidebar. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/P94qs3WCb0fb5Shpvq-Bm_image.png) ### Available attributes: - `ID`: The unique identifier of the job. - `Status`: The current status of the job, which can be one of the following: Finished, Finished with errors, Failed, Running, In Progress, Scheduled, or Canceled. - `Name`: The name of the job. - `Progress bar:` A visual representation of the job's progress, displayed as a percentage. - `Action Type:` The type of action being performed by the job. - `Scheduled Date`: The date and time when the job is scheduled to run. - `Started at: T`he date and time when the job was started. - `Created by`: The user who created the job. - `View job`: An option that expands the details of the current job, providing additional information about its performance and progress. [title] Lifecycle [path] / [title] Logs (Local) [path] Automation Menu/ The Logs feature in the Kubeark Workspace is an useful tool designed to provide users with detailed insights into various activities and events that occur within their workspace. This feature is key for monitoring, auditing, and troubleshooting purposes, as it offers a transparent view of the actions performed, who performed them, and when they were executed. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/-CiAx69a3Y142C9lX7gpf_image.png) ## **Core Capabilities of the Logs Feature** 1. **Filter by Username**: This function allows users to filter log entries based on specific usernames. It is particularly useful for tracking the actions of individual users, enhancing accountability, and facilitating user-specific audit trails. 2. **Filter by Events**: Users can refine the logs to display only certain types of events: - *Added* : Shows logs of all newly created elements within the workspace. - *Updated* : Filters logs to display changes or modifications made to existing elements. - *Deleted* : Reveals logs related to the deletion of elements within the workspace. 3. **Filter by Models**: This feature provides the ability to view logs related to specific models within the workspace, such as: - *Workspace*: Logs pertaining to actions taken within the workspace settings or configurations. - *Workflow*: Shows the history of actions related to workflow creation, modification, or deletion. - *Trigger*: Filters logs for activities associated with setting up or modifying triggers. - *Source*: Reveals logs related to the configuration or changes in data sources. - *Cron Job*: Displays logs for actions taken in relation to scheduling and managing cron jobs. 4. **Filter by Date Range**: Users can specify a date range to view logs from a particular period. This is useful for historical analysis, audit compliance, and identifying trends or patterns over time. ## **Utilizing the Logs Feature** To access and utilize the Logs feature: 1. Navigate to the `Workspace` menu in your Kubeark environment. 2. Select the`Logs` option to access the log entries. 3. Use the available filters (username, events, models, date range) to refine the log data according to your specific needs or investigation requirements. 4. Review the filtered logs to gain insights into the activities and events within your workspace. [title] Web Hooks [path] Automation Menu/Workflows/The Workflow Editor/ The **Webhooks Panel** in the Workflows Editor provides a user interface for managing webhooks associated with workflows. This panel allows users to create, update, execute and manage webhooks efficiently. ![](https://archbee-image-uploads.s3.amazonaws.com/d-khPbgs-rAh0YDTHcYkD-QZkpl06SANghCQ9xMD-Z5-20250509-172939.png "Webhooks Panel") [title] General Settings [path] Automation Menu/Workflows/The Workflow Editor/ The workflow **Settings** modal allows users to configure key settings for a workflow. This modal provides an interface for adjusting the workflow's behavior and execution parameters like **Run Mode** (Parallel, Terminate, Queue)or **Timeout.** ![](https://archbee-image-uploads.s3.amazonaws.com/d-khPbgs-rAh0YDTHcYkD-lG1dPH53A1hJD7RJRXkdl-20250509-173817.png "Settings") [title] Output [path] Automation Menu/Workflows/The Workflow Editor/ The **Output Panel** in the Workflows Editor allows users to define and manage the output fields of a workflow. This panel provides a simple interface for specifying the key-value pairs that represent the workflow's output. [title] Network configuration & Firewall [path] Getting Started/Prerequisites/ :::hint{type="info"} If your network configuration uses an firewall, you must ensure infrastructure components can communicate with each other through specific ports that act as communication endpoints for certain processes or services ::: ### Network Prerequisites The following network prerequisites are necessary to ensure proper operation of the system: 1. **Operating System**: A compatible operating system must be installed on all nodes in the network. Please refer to the [Software requirements]() page 2. **SSH Access: **Secure Shell (SSH) access must be enabled on all nodes in the network to allow for secure remote communication and management. 3. **Time Synchronization (NTP): **Accurate time synchronization via Network Time Protocol (NTP) must be established on all nodes in the network to prevent issues with time-sensitive operations. 4. **DNS**: To prevent potential DNS issues in the cluster, it is essential to ensure that the DNS address in `/etc/resolv.conf` is reachable. 5. **Firewall**: It is required to configure the correct ports to allow communication between infrastructure components if your network is protected by a Firewall or Security Group. You can either disable the firewall or adhere to the recommended setting instructions. 6. Microsoft Azure environment tested with the following `security-group` : | **Services** | **Protocol** | **Action** | **Start Port** | **End Port** | **Comment** | | -------------- | -------------- | ---------- | -------------- | ------------ | --------------------------------------- | | VXLAN traffic | UDP | allow | 4789 | | calico | | ssh | TCP | allow | 22 | | | | rpcbind | TCP | allow | 111 | | use NFS | | nodeport | TCP | allow | 30000 | 32767 | | | metric server | UDP | allow | 8443 | | prometheus metric service | | master | TCP | allow | 10250 | 10258 | | | local-registry | TCP | allow | 5000 | | offline environment | | local-apt | TCP | allow | 5080 | | offline environment | | ipip | IPENCAP / IPIP | allow | | | calico needs to allow the ipip protocol | | https | TCP | allow | 443 | | | | etcd | TCP | allow | 2379 | 2380 | | | dns | TCP | allow | 53 | | | | dns | UDP | allow | 53 | | | | ceph monitor | Any | allow | 3300 | | | | ceph monitor | UDP | allow | 6789 | | | | ceph daemons | Any | allow | 6800 | 7300 | | | calico | TCP | allow | 9099 | 9100 | | | calico | TCP | allow | 5473 | | calico networking with Typha enabled  | | bgp | TCP | allow | 179 | | | | apiserver | TCP | allow | 6443 | | | The `KubeCLI` tool allows for the simultaneous installation of both Kubernetes and Kubeark. For versions of Kubernetes starting from 1.18, it is necessary to install certain prerequisites prior to installation. Please refer to the following list to ensure that all necessary dependencies are installed on your node before proceeding with the installation. | socat | required | | --------- | ------------------------ | | conntrack | required | | ebtables | Optional but recommended | | ipset | Optional but recommended | | ipvsadm | Optional but recommended | [title] Initial Setup [path] How to's/ Below you will find the step by step guide for the initial setup as well as the typical operational flow. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/KZ6HQCeM_AZ2SgiskmHkT_initial-setup1.png) :::hint{type="success"} Please make sure to follow the [Installation guide](docId\:f_B2Z9Q2btzrPc8NttW7h) here before the initial setup. ::: ### Step 1: Login - Go to your preferred browser and access the Kubeark Platform at`https://yourdomain.kubeark.com` - Enter your credentials received from the organzation administrator (or directly from Kubeark) - If the authentication is successful, you will be taken to the Kubeark's platform dashboard where you will see all possible menus and actions according to your role ### Step 2: Cluster configuration According to the operational flow, the first logical step to take in developing your specific deployment is to define the cluster configuration. - On the left-hand side of the main platform interface, go to the `Cluster Management` menu. - Select `Clusters` and here you will find a list with all predefined clusters according to your license and organizational settings - Look for your preferred cluster in the list and make sure the Status is set to `Active` - Here you will also find the `Add existing cluster` option - this menu will open a configuration page where you will be able to add all the attributes for your new cluster. Detailed information about creating a cluster is available here [Clusters](docId\:ICQ1CxzQv6obeZzz_YNVe) ### Step 3: Template Management Once you have selected your clusters, you will need to setup your deployment templates, which can be organized in template groups. Kubeark uses `Groups` as a fundamental aspect of the deployment management system. This acts as a top layer which allows you to track and manage multiple connected apps and deployments in a single, manageable unit. - Go to the `Template Management` menu on the left-hand side of your platform interface. Here you will find the `Groups` and the `Deployments` menus. ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/WULILq5FGTx14ZoJMBT5j_initial-setup-2.jpeg" signedSrc="https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/WULILq5FGTx14ZoJMBT5j_initial-setup-2.jpeg" size="58" width="512" height="348" position="center" caption} - **First, let’s create a new Template Group.** Select `Groups` > `Create template group` Detailed information for creating a new template group as well as the mandatory and optional attributes, can be found here [Template Groups](docId\:K_kBPnulstc8byJkKHTtX) Once you have added all the attributes, click on `Save`. Your newly created template group will appear on the list. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/u-5D7dt-OGWpdTjz4nbEx_create-templ-grp.jpeg) - Now, **let’s start adding templates to the newly created** `Group`. - Select your new group from the list and here you will see the Templates list. - Select the `Create template` option ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/XVyirVfXHSCJIxu3KCdNL_add-tmpl-to-grp.jpeg) - Templates can be added to your group in multiple ways. Kubeark platform will display the following options: ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/dMi3K2ToirUinv4DX6zwt_add-tmpl-to-grp-2.png) - `Create template` - this is the option for creating a template from scratch, using text fields and attributes. Detailed information for creating a new template, as well as an explanation of the mandatory and optional attributes, can be found here [Templates (Kubernetes)](docId\:Eud4OZB9ivS8-u3wW7-fA) - `Upload template` - this option allows you to create a new template by uploading a configuration file. Click or drag a file to the highlighted area and select `Upload`. - `Raw edit` - this option opens an on-screen code editor for manually adding your configuration attributes. Once you have added your configuration, click on `Validate template` and then `Save`. :::hint{type="info"} For uploading a template from a configuration file, the only accepted format is `.json`. For manually configuring the templates using the `Raw edit` option, the accepted configuration formats are .`yaml` and `.json` ::: Great! We have created a new template group and we have now added our preferred templates to the group. All of our templates will show on the list under the `Groups` menu. Next, let’s learn how to deploy the templates we have just created. Let’s deploy our new template: ::::VerticalSplit{layout="left"} :::VerticalSplitItem **Step 1 - Select your preferred Group. **The Groups option on the main Template Management menu displays a list of all your template groups. **Step 2 - Select your preferred Template from the list. **Once you have selected a Group, a list of all your templates will display. **Step 3 - Select the Deploy Template option. **This is the template details page which shows relevant status information about each deployment. ::: :::VerticalSplitItem ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/mXOC1oSYGGuPllNt2H1ao_select-prf-grp.png) ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/BPkp_Ux2XgH16aEC2w_Ij_select-prf-tmpl.png) ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/0KDRf9CGd5Ln1g9OwGGLg_select-depl-tmpl-large.jpeg) ::: :::: ### Step 4: Manage your Deployments - From the `Templates Management` main menu, select `Deployments` ::Image[]{src="https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/F92wnb6VGeOu9NUQI1LjN_mg-depl.png" signedSrc="https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/F92wnb6VGeOu9NUQI1LjN_mg-depl.png" size="60" width="518" height="334" position="center" caption} - Here you will see a list of all your Deployments as well as relevant information such as status, resource utilization and others. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/Y90K9XvfC-7zH3-zypey6_mg-depl-2.png) - Select your newly created deployment and validate all your deployment details for consistency. The available menu displays information about the `Resources`, `Details`, `Update`, `Revision` and `Metrics`. | `Resources` | This category displays information about the deployment status, name, API version, Type and offers a set of Actions for editing. | | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `Details` | This menu shows relevant information about your deployment, including Deployment ID, Template ID, Status and Output. | | `Update` | This category allows you to update the settings and configurations of your deployment | | `Revision` | This category displays information about the revision history of your deployment | | `Metrics` | This category displays various metrics related to your deployment, such as:
- **Usage**: Total cost, Total CPU Cost, Total efficiency, Total active hours - **CPU**: Average running CPU Cores, CPU Core Request Avg., Cumulative CPU core-hours allocated - **RAM**: Avg. RAM allocated, RAM Request Avg., RAM Usage avg., RAM Efficiency, Cumulative RAM byte-hours allocated | [title] Core concepts [path] Product Guide/Organization Administration/Untitled/ - **Application**: links Policies with a Provider and holds information such as UI name and icon. - **Source**: a location from which users can be added to Kubeark, such as LDAP connection or OAuth2 connection. - **Provider**: a way for other applications to authenticate against Kubeark, such as OIDC or SAML. - **Policy**: a yes/no gate that evaluates to True or False based on Policy Kind and settings. Used for custom logic, granting/denying access, and more. - **Flows & Stages:** ordered sequence of stages used for user authentication, enrollment, etc. - **Property Mappings**: makes information available for external applications, such as setting user roles in AWS based on group memberships in Kubeark. - **Outpost**: a separate component of authentik that offers services not implemented directly into the authentik core, such as Reverse Proxying. - **System tasks**: longer-running tasks run in the background by Kubeark, such as syncing LDAP sources or backing up the database. [title] Applications [path] Product Guide/Organization Administration/Untitled/ An application links together Policies with a Provider, allowing you to control access. It also holds Information like UI Name, Icon and more. ### Authorization To configure access to applications, you can use Policy Bindings. You can access this feature by selecting an application from the applications list and clicking on the Policy/Group/User Bindings tab. If no users, groups, or policies are bound, then everyone has access to the application. By binding users, groups, or policies, you can grant specific access to selected individuals or dynamically grant access through policies. When multiple policies/groups/users are attached, the Policy engine mode can be configured in order to: - Require users to pass all bindings/be member of all groups (ALL), or - Require users to pass either binding/be member of either group (ANY) ### Appearance Kubeark alloes for customizable parameters. The following aspects can be configured: - `Name`: the name of the application displayed on the application card - `Launch URL`: the URL that the user is directed to when clicking on the application card, which can be left empty or filled with placeholders for dynamic construction of the URL based on logged-in user - `Icon (URL)`: an optional icon URL for the application that can be entered as an absolute URL if no volume is mounted under /media, or uploaded if a mount exists under /media - `Publisher`: the text shown below the application card indicating the publisher of the application - `Description`: subtext displayed on the application card under the publisher information, providing additional details about the application. :::hint{type="info"} Applications are displayed in the following scenarios: - The user has access defined via policies (or the application has no policies bound) - A Valid Launch URL is configured/could be guessed. This consists of URLs starting with `http://` and `https://` ::: ::::Tabs :::Tab{title="Hiding applications"} To hide applications without modifying policy settings and without removing it, you can simply set the *Launch URL* to `blank://blank`, which will hide the application from users. Keep in mind, the users still have access, so they can still authorize access when the login process is started from the application. ::: :::Tab{title="Launch URLs"} To give users direct links to applications, you can use URLs such as`https://kubeark.company/application/launch//`. This will redirect the user directly if they're already logged in, and otherwise authenticate the user, and then forward them. ::: :::: [title] Operational Flow [path] Product Guide/ The Kubeark platform operates on a hierarchical structure, where each level builds upon the previous one. This structure is as follows: 1. Clusters**:** This is the highest level in the hierarchy. The Kubeark platform requires the use of a Kubernetes cluster as the fundamental unit of organisation. The Kubernetes `cluster` is a collection of physical or virtual machines that are connected and operate together to run containerized applications. 2. Template Groups: Groups serve as containers for all the templates that you create. You can have multiple `Groups`, each with its own set of templates. 3. Templates: Templates are the next level in the hierarchy. They are essentially configuration files that define the resources needed for a given deployment. Each Product can have multiple templates, but the number of templates you can create is limited by your license. 4. Versions: Each template can have an unlimited number of versions. The versioning system allows you to track changes made to templates over time, and revert to previous versions if necessary. Only one version of a template can be active at a time, meaning that only the active version can be deployed. 5. Deployments: Finally, the `Deployments` level is where you deploy your templates. Each template that is configured and ready for production becomes an Deployment. You can update the deployment of previous versions to the active version to ensure they are running the latest configuration. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/D7a_Hf7mzFW8FImUZ5dju_op-flow.jpeg) [title] Deployments (Infrastructure) [path] Environments Menu/Kubeark Infrastructure/ ## Overview The "Deployments" component in the Infrastructure section stands as the practical application of the Infrastructure Templates. It is here that the predefined templates are brought to life, initiating the actual process of provisioning and configuring the infrastructure resources as per the configuration set in the templates. Deployments ensure that the resources are instantiated consistently, based on the parameters and configurations specified within the chosen template. To simplify, while the Templates provide the *blueprint*, the Deployments *actualize* them, translating the theoretical configurations into real-world, operational infrastructure components. ## How to create an infrastructure deployment? **Step 1 - Access the Deployments menu** which can be found in the `Infrastructure` section. Here, you will be presented with a list showcasing all previously created deployments. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/Pe5TbVxVpfck_DTHsTlaV_image.png) **Step 2 - Initiate Deployment Creation**: Locate and click the `Create deployment` button ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/p0z0BABxqOeqXfVEEh4hs_depl-infra-2.png) **Step 3 - Select Desired Template:** Upon clicking, a dropdown list will appear containing available infrastructure templates. Browse through and select the template you wish to use for your new deployment. Click `Create` ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/mOSHs6_ORHiE2HtZFTni__image.png) **Step 4 - Deployment Creation Page**: After selecting the template, you will be redirected to the deployment creation page. This space is dedicated to customizing and setting the various arguments and configurations tied to your deployment. Here, you will be able to tailor various settings, parameters, and configurations based on the specifics of the chosen template. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/aV_UMH-4eQg0GCPfeolyA_depl-infra-4.png) | **Argument** | **Description** | | -------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `TemplateName` | Pre-populated based on your previous selection.  | | `Template id` | Pre-populated based on your previous selection. | | `Owner` | Specify the owner responsible entity for this deployment | | `Name` | Specify the name of your deployment | | `Description` | A short description of the deployment | | `Tags` | Add a tag to your new deployment for easy reference | | `Environment action` | This argument allows adding business logic for the environments lifecycle, and can be defined through: -> Terminate - This is when the environment is terminated when the default timeand grace timereaches 0 seconds-> Manual - Manual trigge | | `ETA` | The default expiration time when the environment action is triggered. Select date from calendar. | | `Grace time ` | The grace time to wait after the default time for the environment action to be triggered. | | `Input variables` | Variables are used to generate random data. You can use them in the values field of the extra arguments section. You can combine them with other values. For example, \{\{set\_string}} - test the result will be a random string followed by the word test. You can also use them in a payload from a value of extra arguments, combined with other values or predefined variables.
The following predefined variable categories are available:
-> `Infra`
-> `User`
-> `Function`
Additional parameters can also be added, the platform supporting various formats such as *string, numeric, JSON, Code, List or Boolean* | **Step 5 - Finalize Deployment**: Once you've made all necessary customizations and reviewed your configurations for accuracy, Kubeark offers you two options, select the one that best suits your deployment needs. ::::VerticalSplit{layout="middle"} :::VerticalSplitItem **Deploy & Plan ** ::: :::VerticalSplitItem **Deploy & Apply** ::: :::: ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/HhBIP2u5DOxg6_p8dVXRh_depl-infra-5.png) [title] Identification stage [path] Product Guide/Organization Administration/Untitled/Untitled/ The Identification stage provides a form for users to identify themselves, where administrators can select the fields that users can use to identify themselves such as email or username. The stage offers two templates: Login and Recovery. The template displays the configured Sources below the login form and links to the Enrollment and Recovery flows, while the template only displays the form. Additionally, administrators can specify whether or not to link the Enrollment and Recovery flows on the form. The enrollment flow is linked as "`Need an account? Sign up`." and the recovery flow is linked as "`Forgot username or password?`". [title] Toolbar [path] Automation Menu/Workflows/The Workflow Editor/ ## Overview The **main toolbar** provides a comprehensive set of tools and actions for managing workflows in the editor. Below is a detailed guide to the toolbar's features and functionality. ![](https://archbee-image-uploads.s3.amazonaws.com/d-khPbgs-rAh0YDTHcYkD-jMHiUMR1IKS24DdYFmH3v-20250509-125501.png) The toolbar is divided into two main sections: - Left Section: Contains workflow-related actions such as saving, publishing, and exiting the editor. Here you can also find the **Run*** *button that executes the workflow. - Right Section: Contains additional tools for managing workflow settings, execution history, outputs, scheduled workflows, triggers, webhooks and more. ## Toolbar Actions - [Publish and Revisions](https://docs.kubeark.com/publish-and-revisions) - [Run Workflow](https://docs.kubeark.com/run) - [Execution History](https://docs.kubeark.com/execution-history) - [Output](https://docs.kubeark.com/output) - [Scheduled Executions](https://docs.kubeark.com/scheduled-executions) - [Workflow Triggers](https://docs.kubeark.com/workflow-triggers) - [Web Hooks](https://docs.kubeark.com/web-hooks) - [General Settings](https://docs.kubeark.com/general-settings) [title] Execution History [path] Automation Menu/Workflows/The Workflow Editor/ The **Execution History Panel** provides users with a detailed view of past workflow executions, including their statuses, timestamps, and other relevant details. This feature is essential for monitoring and debugging workflows. The **Execution History Panel** can be accessed via the **History Button** in the toolbar. Clicking the button opens the panel, typically on the right side of the editor. ![](https://archbee-image-uploads.s3.amazonaws.com/d-khPbgs-rAh0YDTHcYkD-KlmUT-FT44YSHCGzncJ1i-20250509-144213.png "Execution History Panel") ## Execution Details Click an execution in the **Execution History Panel** to open the **Execution Details Panel**. ![](https://archbee-image-uploads.s3.amazonaws.com/d-khPbgs-rAh0YDTHcYkD-hqb7zbz3xH9xmxQrOkBWd-20250509-172419.png "Execution Details Panel") ## Purpose The purpose of the **Execution History** panel is to display a chronological list of workflow executions. Provides detailed information about each execution, such as: - Execution status (e.g., Success, Failed, In Progress, Terminated). - Timestamp of execution. - Execution duration. - Execution Id ## Features 1. **Execution List**: Displays all past executions in a scrollable list. 2. **Execution Details**: Clicking on an execution entry opens a detailed view with additional information for each execution such as: error messages (if applicable), input/output data. 3. **Filters**: Allows users to filter executions The **Execution History Panel **is a powerful tool for tracking and managing workflow executions, enabling users to maintain workflow reliability and performance. [title] Run [path] Automation Menu/Workflows/The Workflow Editor/ The** Run Button** in the Workflow Editor toolbar allows users to execute the current workflow. This feature is essential for testing and validating workflows in real-time. The Run Button is located in the left section of the toolbar, alongside other workflow management actions like Save and Publish ## How to Use The Run Button triggers the workflow execution and will open the **Execution Details** panel to display execution details or logs. 1. Ensure the workflow is in a valid state (e.g., not locked or disabled). 2. Click the **Run Button** to execute the workflow. 3. Monitor the execution results in the **Execution Details** panel. ![](https://archbee-image-uploads.s3.amazonaws.com/d-khPbgs-rAh0YDTHcYkD-6i4GR81TTKHi97B-p9lhn-20250509-143434.png "Execution Details Panel") ## Best Practices - **Validate Workflow**: Ensure the workflow is properly configured before running it. - **Monitor Execution**: Use the Execution Details panel to review the results of the execution. - **Permissions**: Verify that you have the required permissions to execute workflows. The **Run Button** is a critical tool for testing workflows, enabling users to ensure their workflows function as intended. [title] Workflow Triggers [path] Automation Menu/Workflows/The Workflow Editor/ The **Triggers Panel** in the Workflows Editor provides a user interface for managing triggers associated with the current workflow. ![](https://archbee-image-uploads.s3.amazonaws.com/d-khPbgs-rAh0YDTHcYkD-62gQ2x_yTZxq5q2jkFSDj-20250509-170106.png "Triggers Panel") ## Overview The Triggers Panel allows users to: - Create or manage existing triggers. - Filter triggers based on specific criteria - View detailed information about a trigger. - **Capture live events** for a specific trigger ## Create Trigger A **Create Trigger** button is available at the top-right corner of the panel. Clicking this button opens a form in a drawer where users can define a new trigger. ## Expression Builder The **Expression Builder** provides a tool for creating or editing complex trigger expressions. This tool is accessible from the trigger creation/editing form. ![](https://archbee-image-uploads.s3.amazonaws.com/d-khPbgs-rAh0YDTHcYkD-n27T98VGgPxb6bBS9R42W-20250509-170634.png "Expression Builder") [title] Working area [path] Architecture/Platform Interface/ The Working Area is the central part of the Kubeark Platform web application. This is where users interact with the features and functionalities of the platform. The resources accessed through the left side menu are displayed and available for the user to perform their usual actions, depending on the user's rights and permissions. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/s_hm-MshPRBa0VWr_cJ5f_image.png) [title] Scheduled Executions [path] Automation Menu/Workflows/The Workflow Editor/ The **Scheduled Executions Panel** allows users to manage and monitor scheduled executions of workflows. The **Scheduled Executions Panel** can be accessed via the **Scheduled Executions Button** in the toolbar. Clicking the button opens the panel, typically on the right side of the editor. ![](https://archbee-image-uploads.s3.amazonaws.com/d-khPbgs-rAh0YDTHcYkD-1k_SIGAc_6D5dMLYDFcxY-20250509-164606.png) ## Functionality The **Scheduled Executions Panel **enables users to view a list of schedule workflow executions that will run automatically at a predefined date and time. To schedule an execution, use the **Schedule Execution** option from the **Run Button** dropdown menu. This panel provides an overview of all scheduled executions, including their configurations and statuses. [title] The Code Editor [path] Automation Menu/Workflows/The Workflow Editor/ For users who prefer to work directly with the workflow’s code, this button opens up a code editor. This editor allows for viewing and editing the workflow manifest, offering a more technical and detailed approach to workflow management. It caters to users who are comfortable with direct code manipulation or who need to make advanced customizations. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/G8VC7as3KeeQhpBzJU3OG_image.png) ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/U1s1G59YFIo9qyzW884-m_image.png) **Example** > \# Define the workflow with two nodes > > \- name: node_python_script > action: Python > input: > script: | > \# Python code to write a simple message to a text file > with open('output.txt', 'w') as file: > file.write('Hello, this is a test message.') > kind: action > > \- name: node_http_request > action: HTTPRequest > input: > method: GET > url: https://example.com/api/data > authentication: > type: Basic > username: user > password: pass > kind: action > [title] Deployments (Kubernetes) [path] Environments Menu/Kubernetes/ A **Kubeark Deployment** is a representation of the desired state of an application as a collection of persistent objects in the Kubernetes ecosystem. These deployments can only be created by an active `user` or `service account` with the appropriate permissions to create the application in a `cluster` or `multiple clusters` using a specified template. The Kubeark `Application` is cloud agnostic, and relies on a Kubernetes infrastructure, providing an enhanced version of a traditional Kubernetes deployment. The Kubeark deployments allow users to deliver monolithic, containerized applications as multi-tenant by creating namespaced deployments defined in `templates`. As an end-user of the Kubeark platform, when the `Deployment` is triggered, a user account can be created with limited standard permissions. This feature allows for a more efficient and secure way of delivering and managing applications within a Kubernetes environment. ### Create new Deployment Step-by-step guide on how to create an Deployment: - Under the Environments section > Kubernetes > `Deployments`. Press the `Create deployment` button to start ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/dDFPWNUo8DPTbbpJkga6h_image.png) - First, select the `Template Group`, then the `Template` and `Template Version` you want the `Deployment` to be associated with ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/ZD0B9g5ZAuF_bxSP-0mqh_depl2.png) - Select the `Create` option based on your chosen Template. - The `Template Name` field will automatically be filled in with the name of the template you have selected. This field is locked and cannot be modified. - Select cluster: this is a dropdown whith all available clusters, allowing you to choosewhere the new deployment will be created - Name: Provide a name for your Deployment in the `Name` field. This is a mandatory field. - Namespace: this is a mandatory field - `Schedule it?` This toggle enables an additional field called Start time, which allows you to select the desired scheduled date and time - `Owner`: here you can add information about the deployment owner - `Description:` here you have the option to provide a brief description of the purpose of your deployment - `Environment action:` this is a dropdown where you can select between `Manual`, `Stop` and `Terminate` ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/NB7xD-s8sLYK2z_8A4QeZ_depl-3.png) - Add Additional parameters :::hint{type="warning"} All attributes in red are **mandatory** ::: - Press the `Deploy` button to complete the creation of your deployment. :::hint{type="info"} **Note**: To create a `Deployment`, you need to have a valid Template created. ::: [title] Cron Jobs [path] Automation Menu/ Cron jobs in Kubeark are a powerful feature designed for scheduling and automating tasks at predetermined times or intervals. Originating from the Unix-like operating systems, a cron job allows you to run specific scripts or commands automatically at specified times and dates. This functionality is particularly useful for routine tasks like data backups, system updates, or batch processing. In Kubeark, cron jobs are integrated into the platform's workflow, enabling users to automate complex operations within their defined environment. The flexibility of cron scheduling allows for configuring tasks to run yearly, monthly, weekly, or even down to specific minutes, ensuring that operations are performed precisely when needed. This feature is essential for maintaining regular maintenance tasks, automating repetitive processes, and ensuring that critical functions occur at the right times without manual intervention. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/o-ymgFsA582c1jIDA1Kvc_image.png) ## How to Set **Up a Cron Job in Kubeark** 1. **Navigate to Cron Jobs**: Go to `Automation` > `Workspace` > `Cron Jobs` menu. This will take you to the section where you can manage and create new cron jobs. 2. **Select Workspace**: Choose your desired workspace from the dropdown menu located in the upper right corner of the interface. This ensures that the cron job you are creating is associated with the correct workspace. 3. **Initiate Cron Job Creation**: Click on `Select Cron Job`. This action will lead you to the cron job creation interface. 4. **Configure Cron Job Arguments**: - **Name**: Assign a distinctive name to your cron job for easy identification. - **Description**: Provide a brief but clear description of what the cron job does. - **Owner**: Specify the owner or the responsible party for this cron job. - **Workflow**: Select a workflow from the dropdown list. This is the workflow that will be triggered by the cron job. - **Predefined Schedule**: Choose from a dropdown of classic cron expressions (like every year, every month, every week, every day, etc.) for common scheduling needs. - **Schedule**: For more specific scheduling requirements, enter a custom cron expression in the provided field. 5. **Save the Cron Job**: After entering all the necessary information and setting up the schedule, click on “Save” to finalize the creation of your cron job. Your job will now run according to the specified schedule, automating the chosen workflow at designated times. [title] Invitation stage [path] Product Guide/Organization Administration/Untitled/Untitled/ This stage enables user invitation and enrollment with preconfigured values. It can be utilized even when an invitation token is not present, if the option "Continue Flow without Invitation" is enabled. To verify if a user has used an invitation within a policy, the code "request.context.get("invitation\_in\_effect", False)" can be used. To use an invitation, the URL "[https://authentik.tld/if/flow/your-enrollment-flow/?itoken=invitation-token](https://authentik.tld/if/flow/your-enrollment-flow/?itoken=invitation-token)" can be accessed. To prompt the user for an invite, the Prompt stage can be used along with a field key of "token". [title] Publish and Revisions [path] Automation Menu/Workflows/The Workflow Editor/ The **Publish** and **Revisions** features in the Workflow Editor allow users to manage workflow versions effectively. Below is a detailed guide to these functionalities. ## Publish Workflow The **Publish** feature enables users to starts saving a workflow as a new version. Publishing a workflow creates a new revision for tracking changes. ![](https://archbee-image-uploads.s3.amazonaws.com/d-khPbgs-rAh0YDTHcYkD-WBhprdLIp9ZV4DJn54M7A-20250509-140757.png "Publish and Revisions") ### How to Publish a Workflow 1. **Access the Toolbar**: Locate the Publish button in the toolbar (if the workflow was not already published). 2. Click **Publish**: If the workflow is valid and ready, clicking the Publish button will create a new revision. 3. **Disabled State**: The Publish button is disabled if: The workflow is locked or user has read-only or execute-only permissions. Ensure you have the necessary permissions and that the workflow is unlocked. ## Revisions The Revisions feature allows users to view and manage the history of workflow changes. Each time a workflow is saved or published, a new revision is created. ### How to Access Revisions 1. Go to **Workflow Name Button **in the main toolbar: - The workflow name in the toolbar acts as a button when the workflow is published. - Click the workflow name to open the **Revisions** panel. 2. **View Revision**: The panel displays a list of all revisions, including details such as: Revision number, timestamp of creation, current active draft. ## Best Practices - **Save Frequently**: Save your workflow often to create meaningful revisions. - **Publish When Ready**: Only publish workflows that are complete and ready for execution. - **Use Revisions for Rollback**: If a workflow encounters issues, use the Revisions panel to roll back to a stable version. These features ensure that workflows are version-controlled, enabling efficient management and tracking of changes. [title] Save as Action [path] Automation Menu/Workflows/The Workflow Editor/ # Overview Imagine you frequently use a specific node configuration in multiple workflows. Instead of manually recreating it each time, you can save it as an action and quickly reuse it whenever needed. The **Save as Action** button allows users to save the current node as a predefined action. This feature is particularly useful for reusing commonly configured nodes in workflows, saving time and ensuring consistency. The button will save the current node with its field values as a reusable action. The button is only enabled when the node is eligible to be saved as an action. ## How to Use 1. Configure the node with the desired field values. 2. Ensure the button is enabled or present (it will be hidden if the node is not eligible or if certain conditions are not met). 3. Click the Save as Action button to save the node. 4. Complete the required fields like status and metadata (author, category, thumbnail, etc) and choose if you want the action to be global or not. [title] Workflows [path] Automation Menu/ ## Overview Workflows enable users to create and manage stage components within the development lifecycle, customize deployments based on environments, enforce rules and triggers, and create reusable building blocks for streamlined automation. :::hint{type="info"} **Workflows** within Kubeark represent a series of tasks that are executed in a sequential order. These tasks can be initiated through different methods, including manual runs, triggers, and cronjobs. ::: With its low-code approach and event-driven architecture, Workflows enables intelligent responses to events, simplifying automation in the context of Kubernetes. By creating reusable building blocks, Workflows fosters collaboration and accelerates development across teams, providing a solid foundation for efficient and standardized processes. **Workflows** in Kubeark are essential automation canvases and form an integral **part of a Workspace**. They provide a powerful platform where users can design, build, and execute a range of automated tasks and processes, all within the confines of a specific Workspace. This feature enables the orchestration of complex operations, from deployment strategies to intricate infrastructure management. By embedding Workflows within Workspaces, Kubeark ensures a seamless integration of automation within the broader context of resource and project management. With Workflows in Kubeark, you can automate the creation of `Template Groups`, `Templates`, and `Versions`, allowing for streamlined management of your infrastructure as code, ensuring consistent and efficient deployment processes throughout your development lifecycle. `Workflows` can be found in the `Automation` section, under the `Workspace` menu. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/nILwwo37oX1-z9avfTSKr_image.png) ## How does it work? Workflows within Kubeark represent a series of tasks that are executed in a sequential order. The workflow "steps" are defined by Nodes. ### Introducing "Nodes" In the context of workflows, a workflow **node** refers to an individual step or task within a workflow. It represents a discrete unit of work that is executed as part of the overall workflow process. Each node typically has inputs, outputs, and defined behavior or actions associated with it. Nodes can include actions like data transformations, decision points, integrations with external systems, or any other specific task required to accomplish the workflow's objectives. The workflow nodes are connected together to define the sequence and dependencies of the tasks within the workflow. ### Workflow creation simplified A workflow in Kubeark operates through an intuitive and visual process, designed to simplify the creation of your automation workflow. It begins with a set of nodes, each representing a specific action or function, located in the left panel. These nodes can be easily dragged and dropped into the workflow's working area. The working area serves as a canvas where you construct the flow of your automation, visually mapping out each step of the process. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/f_51P4_Bvc2pSESYretN6_image.png) Once a node is placed in the working area, clicking on it reveals options to configure the node with specific arguments. This configuration process adheres to common programming logic, allowing for the setting of arguments and variables in a manner that's both familiar and logical to those with programming experience. The end result is a customized, coherent flow of operations, visually represented and easily adjustable, that encapsulates the desired automation sequence within your Kubeark environment. ### How do I execute a Workflow? Workflows in Kubeark offer versatile execution options, aligning with different operational needs and preferences. Primarily, there are two main perspectives for executing workflows: **(1) *****Instant Execution During Workflow Design*****:** While designing a workflow, users have the option for immediate execution by pressing the "Play" button in the working area. This feature is particularly useful for testing and validation purposes, allowing users to quickly verify the functionality and flow of the workflow in real-time. It provides an on-the-spot method to ensure that each step of the workflow operates as intended before it's put into regular use. This is particularily useful during workflow design and debugging. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/L2vvXs3Wl7ryzwSuHVAjB_image.png) **(2) *****Scheduled or Planned Execution****:* For more controlled and automated operations, workflows can be executed using various scheduling methods, or can be triggered by other workflows within the workspace. This includes: - **Manual Runs**: Users have the ability to manually start a workflow, providing flexibility and control over when and how the tasks are executed. This allows for on-demand execution of specific workflows based on user intervention or decision-making. - **Triggers**: Workflows can also be triggered automatically based on predefined events or conditions. These triggers can be set up to respond to various events within the Kubernetes environment, such as the creation or update of specific resources, changes in configuration, or other custom-defined events. When a trigger event occurs, the associated workflow is automatically initiated, enabling seamless and automated task execution. See [Triggers](docId:-Mo3MoSlQpaek4HeU447O) - **Cronjobs**: In addition to manual runs and triggers, workflows can also be scheduled using cronjobs. Cronjobs provide the ability to define recurring or periodic executions of workflows based on a specific time or schedule. This allows for the automation of repetitive tasks or regular maintenance operations, ensuring that critical processes are performed at designated intervals without the need for manual intervention. See [Cron Jobs](docId\:bPTPuN527wfsRIqGCo2pX) - **Forms**: Workflows can be triggered through user interaction with Forms. When a form is submitted with the required inputs, it can initiate a workflow, effectively linking user input to automated processes. See [Forms](docId\:Fc-zxJNhs77M7CIPNB0eR) - **Webhooks**: External events can trigger workflows via webhooks. When a webhook receives data or a specific event occurs in an external service, it can automatically initiate the associated workflow in Kubeark. - This is particularly useful for integrating with third-party services and systems. - The webhooks trigger option allows the workflow to respond to HTTP callbacks. Users can configure external systems to send webhook events, which in turn trigger the execution of the workflow. This integration provides flexibility in initiating workflows based on specific events or notifications from various external sources. - By leveraging webhooks, users can seamlessly connect their workflows with other systems, enabling powerful automation and orchestration capabilities - ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/u5IVL1x9Vvhd9z-To_Di6_image.png) You will find detailed information about creating a workflow in the dedicated section [Creating a Workflow](docId\:MsL8R-ra4x-BRBjzsRmZi) [title] What is Kubeark [path] Getting Started/ ### Kubeark is the AI automation platform that allows integration of any system in a standardized way Kubeark is the enterprise orchestration platform that revolutionizes business operations through automation. Our mission is to enhance process efficiency, elevate user experience, and enable seamless software management at scale on any technological stack to maximize overall performance and investments. - **Remove Enterprise IT Complexity** - Kubeark helps organizations to regain visibility and unify management on an integrated orchestration platform - **Enhance System efficiency:** Simplify operations and optimize costs by up to 12% by automating workflows that stitch together infrastructure, software and application tasks. - **Empower innovation across the enterprise tech stack: **Fuel experimentation through data-driven decisions based on insights across your hybrid ecosystem ::::Tabs :::Tab{title="Workflow Automation"} Kubeark allows technical teams and end-users to effortlessly create and manage programming language-agnostic workflows and long-running jobs. Users can easily design, execute, and monitor workflows, making the operational processes smoother and more efficient. ::: :::Tab{title="AI Integration"} By leveraging AI, Kubeark helps bridge the gap between disparate systems, ensuring data consistency and reducing integration headaches. This feature supports the automation of complex, end-to-end business processes ::: :::Tab{title="Environment agnostic"} Kubeark is designed for versatility across cloud, hybrid, and on-premises setups. This approach not only supports a business's current infrastructure but also paves the way for future growth and innovation through adaptable, efficient automation strategies ::: :::: ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/pDzGgjdfv8vpSQaNKg7G0_kube-background.jpeg) [title] April 2023 [path] Release Notes/ ## Overview We are pleased to announce the latest release of Kubeark, packed with a host of new features and improvements to enhance your cloud infrastructure management experience. | **Version number** | **Release date** | **Main features** | | ------------------ | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 3.0 | Apr 28, 2023 | - IDP integration - Usage module - Azure Marketplace transactable - Cluster grouping - Centralized management for deployments, clusters and notifications - Bug fixes and performance enhancements | ## IDP integration Kubeark now offers enhanced IDP capabilities, providing secure and reliable authentication services for its users. With support for major providers such as **OAuth2**, **SAML**, **LDAP**, and **SCIM**, administrators can choose the protocol they need for any given scenario. Robust recovery actions are also available for users and applications, including user profile and password management. Administrators can quickly edit, deactivate, or impersonate a user profile, and set a new password for new users or reset an existing password. With these new capabilities, Kubeark offers application developers and security engineers a dependable and secure solution for authentication in virtually any scenario. ## Usage module Kubeark introduces **Usage,** a valuable tool for customers who want to maximize the efficiency and cost-effectiveness of their cloud infrastructure. With its detailed usage and cost analytics, customers can better understand how their resources are being used across different Kubernetes clusters and cloud providers. This offers complete visibility into their cloud infrastructure costs, identify areas of inefficiency, and take proactive steps to improve profitability. Usage enables you to govern: - Cost optimization: insights into usage and spend across Kubernetes clusters and cloud providers - Resource efficiency: identifying and eliminating inefficiencies in resource utilization - Budget tracking: tracking and managing budgets for cloud infrastructure - Analytics and insights: detailed analytics and insights for infrastructure optimization and capacity planning - Efficient scaling: enabling efficient scaling of applications and services - Cost reduction: reducing development costs and accelerating time-to-market for new products and services ## Azure Marketplace transactable module Kubeark has added a new feature that aims to simplify transacting via cloud providers' marketplace. This process can often be challenging due to a lack of understanding and technical issues, as most cloud vendors have specific SLAs that must be met for an order to be fulfilled. While the volume of orders may not be high for certain products, their value is significant. With this new feature, Kubeark aims to automate the entire quote-to-cash process, simplifying the process for ensuring that SLAs are met efficiently. Azure Transact grants the user the capability to design their own form and link the values from the fields with the template data required for deployment. With the Azure transactable module, customers using Kubeark will have the ability to customize their own email templates. The templates will include specific tags that Kubeark Transact will use to automatically insert credentials for the customer. This feature will allow for a more streamlined and customized communication process between Kubeark Transact and the customer, making it easier and more efficient to manage credentials and other important information related to the transaction process. ## Cluster Grouping Cluster Grouping is a new feature added to the Kubeark platform, designed to simplify and streamline the management of multiple Kubernetes clusters. With Cluster Grouping, users can group clusters into logical units based on shared characteristics, such as environment, application, or location. This allows for easier organization and management of clusters, as well as improved visibility into the overall state of the infrastructure. Cluster Grouping will: - allow users to define specific deployment targets based on a predefined set of rules, providing greater control and flexibility in the deployment process. - allows users to deploy resources to specific clusters or groups of clusters based on specific criteria, ensuring that resources are allocated efficiently and effectively. - allows users to easily scale resources across multiple clusters or groups of clusters, providing greater scalability and flexibility in resource management ## [title] August 2023 [path] Release Notes/ ## Overview We are pleased to announce the latest release of Kubeark, packed with a host of new features and improvements to enhance your cloud infrastructure management experience. | **Version number** | **Release date** | **Main features** | | ------------------ | ---------------- | ----------------------------------------------------------------------------------------------------------------------------- | | 4.0 | Aug 1st, 2023 | - Kube Artifacts - Kubeark Infrastructure module - Kubeark Workflows - Kubeark Vault - Bug fixes and performance enhancements | ## Kube Artifacts Kube Artifacts is your one-stop repository for Kubernetes templates, boasting a collection of over 130 ready-to-use configurations. Whether you're aiming to deploy CRMs, CMSs, databases, or a multitude of other products, Kube Artifacts offers a rich selection tailored for diverse business needs. Moreover, its flexible design allows organizations to handpick and make available specific templates that best fit their operational requirements, ensuring a tailored experience for every Kubeark user. Designed with the needs of modern enterprise in mind, Kube Artifacts contains the most frequently utilized services and databases, ensuring that the right teams can effortlessly deploy and manage the most in-demand services with ease. ## Kubeark Infrastructure This feature addresses the need for a centralized and user-friendly solution to manage and customize provider data used in Terraform templates. It focuses on simplifying the configuration of provider-specific information such as authentication credentials, features, and other customization options. The module involves creating a centralized repository to store and manage provider data, where users can select the desired provider in a few simple steps.  Kubeark Infrastructure module will bring numerous benefits, such as: - **Enhanced Productivity**: Simplified configuration process enables faster and more efficient infrastructure provisioning. - **Improved Consistency and Accuracy**: Centralized management ensures reliable and stable deployment with reduced errors. - **Increased Security**: Secure storage and access controls minimize the risk of unauthorized access or credential leakage. - **Flexibility and Scalability:** Easy integration and customization of providers to meet evolving infrastructure needs. - **Streamlined Collaboration**: Central repository promotes efficient teamwork and consistent application of provider settings. - **Time and Cost Savings**: Streamlined process reduces manual effort, minimizes errors, and speeds up deployment cycles. ## Kubeark Workflows Kubeark Workflows is engineered to address the intricacies of deploying software products in multifaceted infrastructure environments, particularly when underpinned by nuanced business logic. At its core, it is more than just a deployment tool; it's a holistic framework that integrates seamlessly with your existing systems. One of the standout features of Kubeark Workflows is its native ability to directly connect to Git repositories. This ensures that your deployment pipelines remain synchronized with the latest code changes, facilitating continuous delivery and integration processes that are both agile and reliable. Moreover, the module's versatility shines when interfacing with web APIs. Regardless of the external systems or services you're employing, Kubeark Workflows can adapt, communicate, and interact with any web API, further expanding its compatibility range. Speed and performance have been paramount in the design of the Workflows module. It's built to impress, capable of managing a staggering 50,000 workflows per minute. Such speed ensures that even the largest-scale deployments occur without a hitch, keeping pace with the demanding rhythms of modern businesses. Lastly, we understand that challenges can arise in any deployment process. That's why Kubeark Workflows comes with an "out of the box" self-healing feature. This ensures that, in the event of minor hiccups or unexpected issues, the system automatically takes corrective actions, ensuring your workflows remain uninterrupted and resilient. ## Kubeark Vault With the increasing complexity of modern applications, managing configuration values consistently and securely has emerged as a daunting challenge. These values, often pivotal for the seamless operation of applications, are scattered across various code files and environments. This dispersion not only complicates the tracking and management of these values but also amplifies the risk of errors, inconsistencies, and, most crucially, security vulnerabilities. Here are some specific challenges observed: - **Error-prone configuration management: **When configuration values are scattered across various code files and environments, it can be difficult to keep track of them all. This can lead to errors, such as using the wrong value or using an outdated value. - **Inconsistent configuration values: **When configuration values are not centralized, it can be difficult to ensure that they are consistent across all components of the application. This can lead to problems such as errors, performance issues, and security vulnerabilities. - **Security vulnerabilities: **When configuration values are not stored securely, they can be exposed to unauthorized access. This can lead to data breaches, financial losses, and reputational damage. To address these challenges, Kubeark Vault offers a centralized repository for managing certain values that are used across multiple components like database credentials, API keys, and environment-specific settings. This ensures that every component of an application references a singular, consistent source for its configurations. Furthermore, the module comes equipped with robust features such as versioning, auditing, and access control, amplifying both efficiency and security. Businesses can now enjoy enhanced application performance, reduced errors, and fortified data security [title] December 2023 [path] Release Notes/ ## Overview We are excited to announce the release of Kubeark v5.0, a significant update that introduces a suite of powerful new features and enhancements. This version, released in December 2023, focuses on expanding the platform's capabilities and user experience with the introduction of Kubeark Forms, Functions, and an enhanced Workspace feature. Each of these additions is designed to streamline processes, increase flexibility, and provide more intuitive and robust tools for managing Kubernetes and infrastructure environments. | **Version number** | **Release date** | **Main features** | | ------------------ | ---------------- | ------------------------------------------------------------------------------------------------- | | 5.0 | December, 2023 | - Kubeark Forms - Kubeark Functions - Kubeark Workspaces - Bug fixes and performance enhancements | ## Forms Forms in Kubeark are interactive components used within Workspaces and Workflows to capture user input and configurations. They provide a user-friendly interface for entering data, setting parameters, and making selections that influence the behavior of Workflows and other Kubeark functions. Forms simplify the process of configuring complex tasks by presenting options in an easily understandable format, ensuring that users can input the necessary information without requiring deep technical knowledge of the underlying systems. This feature enhances the accessibility and efficiency of Kubeark, making it more approachable for users of varying technical expertise. Detailed information here: [Forms](docId\:Fc-zxJNhs77M7CIPNB0eR) ## Functions Functions in Kubeark refer to discrete, reusable operations or actions that can be integrated into Workflows. They are essentially building blocks designed to perform specific tasks within the automation process. Functions can range from simple actions like sending notifications to more complex operations like deploying a cluster or updating a database. The key advantage of Functions is their modularity and reusability, allowing users to create more efficient and maintainable Workflows. By incorporating these Functions into different Workflows, users can optimize their automation processes, reduce redundancy, and ensure consistency across various tasks and projects within Kubeark. Detailed information here: [Functions](docId\:SONgAEeCZqqx1kXGcdCqF) ## Workspaces Workspaces in Kubeark are a key organizational concept, designed to streamline the management of resources and permissions. They serve as a container for grouping related automation components. By using Workspaces, users can efficiently organize their resources based on projects, teams, or any other logical grouping, facilitating easier access and management. This structure enhances collaboration among team members and also ensures better control over access and resource allocation. Workspaces simplify the complexity of managing diverse resources, making it more manageable and intuitive for users to navigate and operate within the Kubeark environment. Detailed information here: [Workspace](docId\:rBBEpzII6ufbiJeDv5xl1) ## [title] October 2024 [path] Release Notes/ ### Platform updates - **New API Gateway** A new API Gateway has been implemented, written in Go, replacing the previous Python-based backend service as the entry point to the platform. This update significantly improves scalability and concurrency, resulting in reduced response times and enhanced performance across the system. - **Kubernetes-Based Filtering and Sorting for Forms and Template Groups** Filtering and sorting capabilities have been introduced for Forms and Template Groups, allowing for better management and organization within the platform. ### Workflows - **OAuth Integration Across Mainstream ID Providers** OAuth capabilities have been expanded in Workflows, to support all mainstream Identity Providers (IDPs), such as GitHub, Salesforce, Google, Microsoft, and others. This enhancement enables users to easily retrieve specific tokens through OAuth providers, improving security and simplifying authentication workflows across multiple services. This will enable users to authenticate using their preferred mainstream IDPs when interacting with forms embedded in workflows. - **Execution History Pagination** Pagination has been added to the workflow execution history, allowing users to more easily browse and manage large volumes of execution data. - **Improved UX in Workflow Execution History** The workflow execution history has been redesigned for improved user experience. New features include clickable child workflow executions, formatted script code, and the ability to wrap text for better readability. - **Workflow Execution Run Modes** Kubeark now supports three distinct workflow execution modes, offering users greater control over how workflows are run: 1. **Parallel**: Existing capability where executions run in parallel. 2. **Terminate**: Each new execution cancels any previous running executions. 3. **Queue**: New executions wait in a queue until previous ones finish. - **Customizable Workflow Timeout** Users can now set custom timeouts for workflows, with the default being 24 hours. This provides flexibility for managing long-running workflows. - **Local and Global Variables** Support for local and global variables has been added within workflows: - **Local Variables**: Created on each script node, allowing users to set and prompt for values directly at the beginning of each node. - **Global Variables**: Predefined variables that can be used throughout the workflow but cannot be created within individual nodes. - **Triggers: Live Event Capture** A new feature for triggers allows users to capture live events without attaching a workflow. This enables real-time monitoring of trigger events, enhancing visibility into system operations. - **Workflow metrics** (*Preview*) - New workflow metrics capabilities are available in preview, providing detailed insights into workflow performance and execution data. ### Webhooks - **Wait for Workflow Execution and Return Output** A new option has been introduced for webhooks, allowing the system to wait for workflow execution to complete and return the output via the webhook. - **Custom URL for Webhooks** *(Preview)* A new feature allows users to specify a custom URL for webhooks, giving more flexibility in how webhooks are handled. ### Dynamic Custom Action Grouping - **Custom Actions Grouping by Category, Author, and Type** Custom actions within workflows can now be organized by category, author, and type, making them easier to manage and search for when building and optimizing workflows. ### Prepaid Option for Workspaces - **Limit Execution Time per Workspace** A prepaid option has been introduced, allowing administrators to set limits on the total execution time for each workspace, helping manage resources more effectively. *** This release brings significant improvements to the Kubeark platform, improving scalability, workflow flexibility, and overall user experience [title] April 2024 [path] Release Notes/ We are excited to announce the April 2024 release (v6) of Kubeark, bringing significant advancements to our platform. This version introduces the Kubey AI Large Action Model (LAM), a groundbreaking feature that allows users to simply describe their desired automation in natural language, and our AI will generate the corresponding workflow and integrate with known systems. Alongside this innovative capability, v6.0 also includes numerous bug fixes and performance enhancements to ensure a smoother, more efficient user experience. ## Kubey AI Large Action Model With Kubey AI LAM, users can generate complex workflows simply by describing their desired automation in natural language. Kubey AI, an integral feature available on the Workflows page. By simply describing the desired automation task in plain text, users can leverage Kubey AI to create fully functional workflows that integrate seamlessly with various systems. ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/gKQ5Rs8ppJrCEz_j1H90J_image.png) ![](https://archbee-image-uploads.s3.amazonaws.com/-uoBIPXCIMlUMvNPPrDxd/rWB2tvkbFqbwaye5wzm9L_image.png)