diff --git a/src/.vitepress/routes/sidebar/versions.ts b/src/.vitepress/routes/sidebar/versions.ts index 028624b..ccb4809 100644 --- a/src/.vitepress/routes/sidebar/versions.ts +++ b/src/.vitepress/routes/sidebar/versions.ts @@ -1,6 +1,14 @@ export const versionRoutes = [ + { + text: '0.1.0', + link: '/v0.1.0' + }, + { + text: '0.0.11', + link: '/v0.0.11' + }, { text: '0.0.10', link: '/v0.0.10' - }, -] \ No newline at end of file + } +] diff --git a/src/guide/admin/data-store-management.md b/src/guide/admin/data-store-management.md index 78a68d7..bf10681 100644 --- a/src/guide/admin/data-store-management.md +++ b/src/guide/admin/data-store-management.md @@ -37,7 +37,7 @@ A description of the fields in the table can be found below. | Access Key (S3 only) | Generated access key used for accessing the listed, private S3 bucket | | Secret Key (S3 only) | Generated secret key used for accessing the listed, private S3 bucket | | Hostname | Name of the server on which the data is located | -| Port | Connection endpoint for accessing the server. Use 80 for HTTP and 443 for HTTPS. If a different protocol is used, please verify which port is accessible | +| Port | Connection endpoint for accessing the server. Use 80 for HTTP and 443 for HTTPS. If a different protocol is used, please verify which port is accessible. Use port 9000 for the bundled MinIO instance. | | Protocol | Protocol used for transferring files | ## Managing Data Access diff --git a/src/guide/deployment/node-installation.md b/src/guide/deployment/node-installation.md index 3b8b354..b5c6196 100644 --- a/src/guide/deployment/node-installation.md +++ b/src/guide/deployment/node-installation.md @@ -4,23 +4,23 @@ This section will provide instructions for deploying the FLAME node software on **These instructions assume that you have done the following:** -- [Node has been registered in the Hub UI](./node-registration#creating-a-node-in-the-hub) -- [Credentials for your node's robot were generated and saved](./node-registration#robot-credentials) -- [A keypair was generated](./node-registration#crypto) and the private key was saved as `private_key.pem` +- [Node has been registered in the Hub UI](./node-registration#creating-a-node-in-the-hub) +- [Credentials for your node's robot were generated and saved](./node-registration#client-credentials) +- [A keypair was generated](./node-registration#crypto) and the private key was saved as `private_key.pem` ## Requirements ### Hardware -- 8 cores -- 16GB (minimum) - 32GB (recommended) RAM -- 100GB storage +- 8 cores +- 16GB (minimum) - 32GB (recommended) RAM +- 100GB storage ### Networking -- Ports 22 and 443 are open -- Access to the internet for communicating with the Hub -- A hostname that directs to the server running the FLAME Node software +- Ports 22 and 443 are open +- Access to the internet for communicating with the Hub +- A hostname that directs to the server running the FLAME Node software ### Software @@ -33,21 +33,23 @@ A quick start guide to installing microk8s and Helm can be found [here](./microk Kubernetes (also known as k8s) is a container management software package which allows for rapid deployment and scaling of multiple applications and service. There are multiple distributions of k8s available for a variety of system configurations. The only requirement for the FLAME Node software is that a network plugin (e.g. Calico) -is installed in your k8s installation to allow for network policy management. Additionally, the DNS provider in -your cluster must use the standard `k8s-app: kube-dns` label on its pods (e.g. CoreDNS or kube-dns deployed via kubeadm). +is installed in your k8s installation to allow for network policy management. Additionally, the DNS provider in +your cluster must use the standard `k8s-app: kube-dns` label on its pods (e.g. CoreDNS or kube-dns deployed via +kubeadm). This label is required so that analysis pods can resolve internal service names through the cluster DNS. Most standard Kubernetes distributions — including microk8s, kubeadm, EKS, GKE, AKS, and k3s — use this label by default. -You can verify this with: - +You can verify this with: + ```bash kubectl get pods -n kube-system -l k8s-app=kube-dns ``` + If this returns no pods, your DNS provider uses a non-standard label and network policy enforcement for analysis pods will not work correctly.The following distributions have been tested for use with the Node software: -- [microk8s](https://microk8s.io/docs/getting-started) -- [minikube](https://minikube.sigs.k8s.io/docs/start/?arch=%2Fwindows%2Fx86-64%2Fstable%2F.exe+download) -- [Kubernetes](https://kubernetes.io/docs/setup/) +- [microk8s](https://microk8s.io/docs/getting-started) +- [minikube](https://minikube.sigs.k8s.io/docs/start/?arch=%2Fwindows%2Fx86-64%2Fstable%2F.exe+download) +- [Kubernetes](https://kubernetes.io/docs/setup/) #### Helm @@ -61,34 +63,34 @@ multi-service software and we highly recommend using this tool for installing th In order to deploy a node, you will need the following pieces of information from the Hub: -1. Robot ID -2. Robot Secret (not hashed!) +1. Client ID +2. Client Secret (not hashed!) 3. Private Key With this information, you can either edit the `values.yaml` file included with the FLAME Node helm chart or create your own values template file to be used during deployment. Here is a minimal example of a values file: ```yaml -global: - node: - ingress: - enabled: true - hostname: https://your.node.ui.domain.com +expose: + type: "ingress" + hostname: https://your.node.ui.domain.com hub: auth: - robotUser: - robotSecret: + clientID: + clientSecret: crypto: privateKey: | - -----BEGIN PRIVATE KEY----- - myExamplePrivateKey - -----END PRIVATE KEY----- + -----BEGIN PRIVATE KEY----- + myExamplePrivateKey + -----END PRIVATE KEY----- ``` -Be sure to enable `ingress` in your values file, otherwise, your hostname will not resolve. +Be sure to set the `expose.type` to either "ingress" or "gateway" in your values file, otherwise, your hostname will +not resolve. -The crypto private key can also be provided using an existing secret. For more information on how to do this, see [Using an Existing Secret for the Crypto Private Key](./node-troubleshooting#using-an-existing-secret-for-the-crypto-private-key). +The crypto private key can also be provided using an existing secret. For more information on how to do this, +see [Using an Existing Secret for the Crypto Private Key](./node-troubleshooting#using-an-existing-secret-for-the-crypto-private-key). ::: info Note The default installation method assumes that if you have SSL enabled (i.e. using HTTPS), then this is handled by @@ -96,22 +98,46 @@ a reverse proxy. If this is not the case, you need to disable the proxy headers example. ::: +### Routing + +Most kubernetes distributions previously used only the Ingress API for routing traffic, but that has been recently +deprecated in favor of the new [Gateway API](https://gateway-api.sigs.k8s.io/). Currently, our helm charts are +designed to support both APIs, but the user must choose one of the APIs to use when deploying the helm chart. We +suggest using "ingress" if you are unsure. + +Though the Gateway API is the currently accepted standard and recommended API to use, it is not automatically +included in all kubernetes distributions. Users should follow this +[guide for installing the Gateway API](https://gateway-api.sigs.k8s.io/guides/getting-started/#installing-gateway-api) +if they haven't done so already and wish to use this API. + +If you are not sure whether this API is already installed in your kubernetes installation, run the following commands: +```bash +kubectl get crd gateways.gateway.networking.k8s.io +kubectl get crd httproutes.gateway.networking.k8s.io +``` +If either command gives an error or returns `NotFound`/`Unhandled Error`, then they are not installed and you cannot +use the "gateway" option for `.expose.type`. + ### Keycloak By default, the FLAME Node package deploys keycloak as part of the installation. The clients and their secrets are -all generated and configured within this included IDP. If you wish to your own IDP, then clients for the Node Hub -Adapter and the Node UI will have to be created and their secrets set in the values template. See the +all generated and configured within this included IDP. If you wish to use your own IDP, then a client for the Node UI +will have to be created and its secrets set in the values template. See the [Using Your Own IDP](#using-your-own-idp) section for more information. #### Role Based Access Control (RBAC) -The node software package supports restricting the actions of certain users with access to the Node UI via RBAC. A + +The node software package supports restricting the actions of certain users with access to the Node UI via RBAC. A user can have one of three roles with the following names and permissions: + * **steward**: can modify/create data stores, but cannot start/stop/delete analyses or view their logs * **researcher**: can start/stop/delete analyses and view their logs, but cannot modify data stores * **admin**: full access -The included Keycloak instance includes these roles by default, and the initially created `flameuser` is given the "admin" role. -The names of these roles can be modified in your `my-values.yaml`, and these changes will be reflected in Keycloak as well: +The included Keycloak instance includes these roles by default, and the initially created `flameuser` is given the " +admin" role. +The names of these roles can be modified in your `my-values.yaml`, and these changes will be reflected in Keycloak as +well: ```yaml rbac: @@ -122,61 +148,80 @@ rbac: ``` ::: warning Role Claim Name -The `roleClaimName` value is specific for how the role is defined in the JWT provided by the bundled Keycloak, and +The `roleClaimName` value is specific for how the role is defined in the JWT provided by the bundled Keycloak, and should not be modified. This only ever needs to be changed if you are [using your own IDP](#using-your-own-idp). ::: -See the [Access Control](/guide/admin/keycloak-access-control#access-control) section of the documentation for more information +See the [Access Control](/guide/admin/keycloak-access-control#access-control) section of the documentation for more +information on how to create users and assign them specific roles. ::: info Disabling RBAC If you have no need for RBAC, it can be disabled by setting `roleClaimName` to an empty string (`""`). ::: - ### Using Your Own IDP For better security, this software uses Keycloak for authenticating the various services and users that make up FLAME. Keycloak is installed along with the other services and is required for the creation and management of the individual analyses. Using the keycloak console, the admin you can add additional users who can access the FLAME UI, but you may -also use your own IDP for user authentication if you wish. +also use your own IDP for user authentication. Here are the values that need to be filled in to achieve this: + +```yaml +userIdp: + ## @param userIdp.hostname Hostname for a separate IDP to manage users who can access the FLAME Node UI. + ## The URL provided should be the issuer URL of the IDP. + ## Leave this blank unless you want to use your own IDP for user authentication + hostname: https://my.own.keycloak.instance.de/realms/myRealm + ## @param userIdp.provider User auth provider. Can be 'keycloak', 'auth0', 'authentik', 'onelogin', 'okta', 'zitadel', or 'hub' + provider: keycloak + +ui: + idp: + clientId: + clientSecret: +``` -To enable this, first you must create individual clients for both the Node UI and the Hub Adapter in your IDP. -Be sure to enable client authentication and take note of the client ID and secret for both of these newly created -clients as this information along with the (accessible) URL for your IDP must be provided in the `values.yaml`. +To enable this, first you must create individual clients for the Node UI in your IDP. +Be sure to enable client authentication and take note of the client ID and secret for this new +client as this information along with the (accessible) URL for your IDP must be provided in your `my-values.yaml`. You +may also need to set the hostname you are using for your node as a valid redirect URI in the client settings. An example of how to configure this in for your cluster can be seen in this separate IDP example. #### RBAC -Admins using their own IDP who also wish to utilize RBAC for the Node UI will need to configure the roles using -their IDP's documentation. Once a the role is created and assigned to a user, the `roleClaimName` value needs to -be modified so that the role can be extracted from the JWT provided by the IDP. The `roleClaimName` value should -contain the keys leading to the role value in the decrypted JWT, with each hierarchical level separated by a + +Admins using their own IDP who also wish to utilize RBAC for the Node UI will need to configure the roles using +their IDP's documentation. Once a the role is created and assigned to a user, the `roleClaimName` value needs to +be modified so that the role can be extracted from the JWT provided by the IDP. The `roleClaimName` value should +contain the keys leading to the role value in the decrypted JWT, with each hierarchical level separated by a period ("."). In this example: + ```json { - "sub": "1234567890", - "name": "John Doe", - "iat": 1516239022, - "access_control": { - "node-ui-client": { - "user-defined-roles": [ - "steward" - ] - } - }, - "scope": "openid email profile", - "email_verified": true + "sub": "1234567890", + "name": "John Doe", + "iat": 1516239022, + "access_control": { + "node-ui-client": { + "user-defined-roles": [ + "steward" + ] + } + }, + "scope": "openid email profile", + "email_verified": true } ``` -the `roleClaimName` should be changed to `"access_control.node-ui-client.user-defined-roles"`. +the `roleClaimName` should be changed to `"access_control.node-ui-client.user-defined-roles"`. ## Installation -At this point, you should have a custom values file (e.g. `my-values.yaml`) which contains the robot credentials and private key for your node. If you have all of this information, then you can proceed with deploying the FLAME Node by +At this point, you should have a custom values file (e.g. `my-values.yaml`) which contains the client credentials and +private key for your node. If you have all of this information, then you can proceed with deploying the FLAME Node by either using the FLAME repo **OR** cloning the Github repository. ::: info Note @@ -229,29 +274,30 @@ is deployed and verified, so please have patience during this step and do not pr ## Proxies -If your server is behind a proxy i.e. all traffic is routed through a specific address and/or port, then the FLAME Node needs to be configured +If your server is behind a proxy i.e. all traffic is routed through a specific address and/or port, then the FLAME Node +needs to be configured to use the same proxy for its requests. -An easy way to tell if a proxy is configured on your machine is to run `echo $HTTP_PROXY` or check the `/etc/environment` file while logged into the server. -If any of the `HTTP_PROXY`, `HTTPS_PROXY`, `http_proxy`, or `https_proxy` variables are populated, then the machine is likely behind a proxy and this address needs to be +An easy way to tell if a proxy is configured on your machine is to run `echo $HTTP_PROXY` or check the +`/etc/environment` file while logged into the server. +If any of the `HTTP_PROXY`, `HTTPS_PROXY`, `http_proxy`, or `https_proxy` variables are populated, then the machine is +likely behind a proxy and this address needs to be added to the `my-values.yaml` file as shown here: ```yaml -global: - node: - ingress: - enabled: true - hostname: https://your.node.ui.domain.com +expose: + type: "ingress" + hostname: https://your.node.ui.domain.com hub: auth: - robotUser: - robotSecret: + clientID: + clientSecret: crypto: privateKey: | - -----BEGIN PRIVATE KEY----- - myExamplePrivateKey - -----END PRIVATE KEY----- + -----BEGIN PRIVATE KEY----- + myExamplePrivateKey + -----END PRIVATE KEY----- proxy: httpProxy: "http://my.example.proxy.de:3128" @@ -259,14 +305,18 @@ proxy: noProxy: "10.0.0.0/8,192.168.0.0/16,127.0.0.1,172.16.0.0/16,.svc,localhost,.cluster.local" ``` -The `NO_PROXY`/`no_proxy` value will depend on your kubernetes distribution and your server configuration, please check your kubernetes distribution's documentation for suggested values. -It is highly recommended that you add the the DNS A record to the `noProxy` value for the cluster in which you are deploying the FLAME Node. The name for this record takes the +The `NO_PROXY`/`no_proxy` value will depend on your kubernetes distribution and your server configuration, please check +your kubernetes distribution's documentation for suggested values. +It is highly recommended that you add the the DNS A record to the `noProxy` value for the cluster in which you are +deploying the FLAME Node. The name for this record takes the form of `` and by default is equal to `.cluster.local`. ## Additional Certificate Authority (CA) Certificates -Some locations may have additional, self-signed SSL/TLS certificates that they use for monitoring web traffic on their servers. In this case, problems can occur that pre-mature SSL termination -occurs and the node services cannot communicate with the Hub. To avoid this, these self-signed CA certificates need to be provided to the node during deployment. This can be done by providing +Some locations may have additional, self-signed SSL/TLS certificates that they use for monitoring web traffic on their +servers. In this case, problems can occur that pre-mature SSL termination +occurs and the node services cannot communicate with the Hub. To avoid this, these self-signed CA certificates need to +be provided to the node during deployment. This can be done by providing the CA files either: 1. In the `helm/charts/flame-node/certs` directory and installing using a local version of the helm chart @@ -274,10 +324,14 @@ the CA files either: ### Using the `certs` Directory -By cloning the [helm repository](https://github.com/PrivateAIM/helm), one can provide the CA PEM files in the `helm/charts/flame-node/certs` directory and then perform a `helm install` using the modified -local helm chart, and the files will automatically be imported as a ConfigMap and provided to the necessary services. The CA certificates need to be in PEM format (i.e. `*.pem`) and -ideally, they are all concatenated into a single file. If there are multiple files, place them all (in order) in the `certs/` folder, and the deployment will automatically concatenate them for you. -In the example below, a user copies their institution's self-signed CA certificate into the `certs/` directory and names it `myCA.pem` +By cloning the [helm repository](https://github.com/PrivateAIM/helm), one can provide the CA PEM files in the +`helm/charts/flame-node/certs` directory and then perform a `helm install` using the modified +local helm chart, and the files will automatically be imported as a ConfigMap and provided to the necessary services. +The CA certificates need to be in PEM format (i.e. `*.pem`) and +ideally, they are all concatenated into a single file. If there are multiple files, place them all (in order) in the +`certs/` folder, and the deployment will automatically concatenate them for you. +In the example below, a user copies their institution's self-signed CA certificate into the `certs/` directory and names +it `myCA.pem` ```bash ├── CHANGELOG.md @@ -300,8 +354,10 @@ In the example below, a user copies their institution's self-signed CA certifica ### Using a Pre-Defined ConfigMap -Similar to how one can create a kubernetes Secret and provide that to the `values.yaml`, one can also create a custom ConfigMap containing the certificate and use that instead. The certificate must be -named `certs.pem` and if you have multiple self-signed certificates to provide, they must all be contenated into that one file. +Similar to how one can create a kubernetes Secret and provide that to the `values.yaml`, one can also create a custom +ConfigMap containing the certificate and use that instead. The certificate must be +named `certs.pem` and if you have multiple self-signed certificates to provide, they must all be concatenated into that +one file. Now, create your custom ConfigMap (in this example it is named `my-certs`) using that file: @@ -317,49 +373,51 @@ certificateConfigMap: "my-certs" Your `my-values.yaml` can then be used during deployment to provide the certificates. - ## Deploying without a Domain Name -It is highly recommended to deploy the FLAME Node using a domain or hostname that is configured within your institution's DNS or proxy. However, +It is highly recommended to deploy the FLAME Node using a domain or hostname that is configured within your +institution's DNS or proxy. However, there may be circumstances in which you want to deploy the software without providing an accessible domain or hostname. In such cases, thee are a couple of options for configuring the FLAME Node such that you can still access the Node UI. -1. Those with access to the server running the services can [port forward](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_port-forward/) the individual containers for each of the services and access them in their browser using the forwarded ports +1. Those with access to the server running the services + can [port forward](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_port-forward/) the individual + containers for each of the services and access them in their browser using the forwarded ports 2. On one or multiple machines, manually map the IP address of the FLAME Node server to a hostname ### Port Forward -#### Disable Ingress -When deploying the FLAME node without a hostname, the values file must be configured to disable ingress for the +#### Disable Routing + +When deploying the FLAME node without a hostname, the values file must be configured to disable routing for the services: ```yaml -global: - node: - ingress: - enabled: false - hostname: "" +expose: + type: "none" + hostname: hub: auth: - robotUser: - robotSecret: + clientID: + clientSecret: crypto: privateKey: | - -----BEGIN PRIVATE KEY----- - myExamplePrivateKey - -----END PRIVATE KEY----- + -----BEGIN PRIVATE KEY----- + myExamplePrivateKey + -----END PRIVATE KEY----- ``` -Be sure to still populate the `robotUser` and `robotSecret` with the credentials obtained from the Hub as well as the private key for the result service. +Be sure to still populate the `clientID` and `clientSecret` with the credentials obtained from the Hub as well as the +private key for the result service. #### Accessing the Services -Once you have deployed the FLAME Node with the ingress disabled, three services need to be port-forwarded: +Once you have deployed the FLAME Node with routing disabled, three services need to be port-forwarded: -- Node UI -- Hub Adapter -- Keycloak +- Node UI +- Hub Adapter +- Keycloak ##### Get the Service Names @@ -389,33 +447,53 @@ Now you can access these services in your browser. For example, to access the No `http://localhost:3000`. ### Map a Hostname -It is possible to override a DNS entry by manually mapping an IP address to a hostname or URL in your local `hosts` file. On Unix systems, -this file is often located at `/etc/hosts` and it Windows it can be found at `C:\windows\system32\drivers\etc\hosts`. If you choose to do this, + +It is possible to override a DNS entry by manually mapping an IP address to a hostname or URL in your local `hosts` +file. On Unix systems, +this file is often located at `/etc/hosts` and it Windows it can be found at `C:\windows\system32\drivers\etc\hosts`. If +you choose to do this, only the machines with this manual configuration will be able to access the Node UI. #### Enable Offline Mode -Because the provided hostname is only resolvable on those machines for which the hostname and IP were manually mapped to one another, the k8s -cluster will not be able to find the other services using this name. Thus, when deploying the FLAME Node in this manner, the Node UI and Hub Adapter -must have `offline` set to `true` in their configurations so that they can still communicate with the included keycloak instance for client authentication. -Other settings can be left as though a FQDN is being used including enabling ingress and providing the locally resolvable hostname. Your `values.yaml` should +Because the provided hostname is only resolvable on those machines for which the hostname and IP were manually mapped to +one another, the k8s +cluster will not be able to find the other services using this name. Thus, when deploying the FLAME Node in this manner, +the Node UI and Hub Adapter +must have `offline` set to `true` in their configurations so that they can still communicate with the included keycloak +instance for client authentication. + +Other settings can be left as though a FQDN is being used including enabling routing and providing the locally +resolvable hostname. Your `my-values.yaml` should look similar to this: + ```yaml -global: - node: - ingress: - enabled: true - hostname: http://your.locally.resolvable.hostname +expose: + type: "ingress" + hostname: http://your.locally.resolvable.hostname hub: auth: - robotUser: - robotSecret: + clientID: + clientSecret: crypto: privateKey: | - -----BEGIN PRIVATE KEY----- - myExamplePrivateKey - -----END PRIVATE KEY----- + -----BEGIN PRIVATE KEY----- + myExamplePrivateKey + -----END PRIVATE KEY----- offline: true ``` + +## (Optional) Node Data Store +The `flame-node` helm chart includes the `flame-node-data-store` subchart which can be used to deploy a FHIR server (blaze) and/or an S3 server (MinIO) in addition to the node software components. These servers can store data that can be used for running analyses. Ideally, these are used only for development and testing purposes. + +You can enable these services through your `my-values.yaml` file: + +```yaml +dataStore: + enabled: true + minio: + rootUser: "" + rootPassword: "" +``` \ No newline at end of file diff --git a/src/guide/deployment/node-registration.md b/src/guide/deployment/node-registration.md index acb50c2..99d89ac 100644 --- a/src/guide/deployment/node-registration.md +++ b/src/guide/deployment/node-registration.md @@ -59,16 +59,16 @@ Be sure to click "Save" when you generate a new key pair, otherwise the public k key used during deployment will not be from the same pair. ::: -### Robot Credentials +### Client Credentials -On this page, there are two pieces of information required for the deploying the FLAME Node: the robot ID and secret. +This page contains two pieces of information required for the deploying the FLAME Node: the client ID and secret. Because the secret was automatically created when the node was registered and then hashed, we need to generate a new one. Click the "generate" button below the secret text field to create a new secret and copy this string somewhere -for later. Then click "update" and you will see a green text box appear indicating that the robot secret +for later. Then click "update" and you will see a green text box appear indicating that the client secret for this node was successfully updated. -[![Getting Robot Credentials](/images/ui_images/hub_node_robot_credentials.png)](/images/ui_images/hub_node_robot_credentials.png) +[![Getting Client Credentials](/images/ui_images/hub_node_robot_credentials.png)](/images/ui_images/hub_node_robot_credentials.png) ::: warning Don't Copy the Hashed Secret! If you see "hashed" next to the word secret above the text field, this means the value in the box below is hashed and @@ -76,7 +76,7 @@ cannot be used for the node deployment. If this is the case, and you have lost o simply generate a new one and update it. ::: -For deployment, we need the previously generated secret and the robot **ID**. Copy the ID to the same location you +For deployment, we need the previously generated secret and the client **ID**. Copy the ID to the same location you copied the secret. Now, you have everything needed for deploying the node software on your system. diff --git a/src/public/files/values_no_reverse_proxy_example.yaml b/src/public/files/values_no_reverse_proxy_example.yaml index 65fc841..9264ab2 100644 --- a/src/public/files/values_no_reverse_proxy_example.yaml +++ b/src/public/files/values_no_reverse_proxy_example.yaml @@ -1,13 +1,11 @@ -global: - node: - ingress: - enabled: true - hostname: https://your.node.ui.domain.com +expose: + type: "ingress" + hostname: https://your.node.ui.domain.com hub: auth: - robotUser: - robotSecret: + clientID: + clientSecret: crypto: privateKey: | -----BEGIN PRIVATE KEY----- diff --git a/src/public/files/values_separate_idp.yaml b/src/public/files/values_separate_idp.yaml index 553e68b..47c7f2d 100644 --- a/src/public/files/values_separate_idp.yaml +++ b/src/public/files/values_separate_idp.yaml @@ -1,13 +1,11 @@ -global: - node: - ingress: - enabled: true - hostname: https://your.node.ui.domain.com +expose: + type: "ingress" + hostname: https://your.node.ui.domain.com hub: auth: - robotUser: - robotSecret: + clientID: + clientSecret: crypto: privateKey: | -----BEGIN PRIVATE KEY----- @@ -19,13 +17,10 @@ userIdp: ## The URL provided should be the issuer URL of the IDP. ## Leave this blank unless you want to use your own IDP for user authentication hostname: https://my.own.keycloak.instance.de/realms/myRealm + ## @param userIdp.provider User auth provider. Can be 'keycloak', 'auth0', 'authentik', 'onelogin', 'okta', 'zitadel', or 'hub' + provider: keycloak ui: idp: clientId: clientSecret: - -hubAdapter: - idp: - clientId: - clientSecret: diff --git a/src/versions/v0.0.10.md b/src/versions/v0.0.10.md index 6e90077..f5badd5 100644 --- a/src/versions/v0.0.10.md +++ b/src/versions/v0.0.10.md @@ -1,4 +1,4 @@ -# Upgrading to v0.0.10 +# v0.0.10 > This release contains breaking changes for the `flame/flame-node` helm chart ## Node @@ -42,4 +42,4 @@ Several small updates were made to the analyses table: Log windows for analyses now have a "Copy to clipboard" and "Download" buttons and the the refresh toggle is enabled by default if an analysis is "running". ### Backend -Several fixes were applied to improve stability, with a focus on improving analysis startup routine. \ No newline at end of file +Several fixes were applied to improve stability, with a focus on improving analysis startup routine. diff --git a/src/versions/v0.0.11.md b/src/versions/v0.0.11.md new file mode 100644 index 0000000..2c8a8f5 --- /dev/null +++ b/src/versions/v0.0.11.md @@ -0,0 +1,12 @@ +# v0.0.11 + +## Node +### Helm +Several performance modifications were made to improve deployment and a fix was applied to allow UI sign in when +ingress is disabled + + +### UI +#### Private S3 Bucket Data Stores +Private buckets are now supported when creating a data store using an S3 bucket. Full documentation on how to do this +can be found [here](https://docs.privateaim.net/guide/admin/bucket-setup-for-data-store.html). diff --git a/src/versions/v0.1.0.md b/src/versions/v0.1.0.md new file mode 100644 index 0000000..aebb775 --- /dev/null +++ b/src/versions/v0.1.0.md @@ -0,0 +1,123 @@ +# v0.1.0 + +> This release contains breaking changes for the `flame/flame-node` helm chart + +## Node + +In an effort to ensure long-term support, we have added the ability to use the kubernetes Gateway API in addition to the +Ingress API since the latter has been deprecated. This resulted in having to make a breaking change to the `values.yaml` +file to support both APIs. This means that values files from prior versions are not compatible with this new helm chart. +Users will have to update their `values.yaml` file in order to upgrade to `v0.1.0`. + +### Breaking Changes + +#### Removed global Values + +The `global` section at the top of the `flame-node` helm chart `values.yaml` +file. This was previously used to simplify distributing the provided hostname to the chart and its +sub-charts, but is no longer necessary so it was removed. Likewise, the ingress sections for both this helm chart and +the sub-charts were removed. + +```diff +-global: +- node: +- ingress: +- enabled: false +- hostname: ++expose: ++ type: none ++ hostname: "" ++ tls: ++ secretName: "" ++ ingress: ++ className: "" ++ annotations: {} ++ pathType: ImplementationSpecific ++ gateway: ++ gatewayClassName: nginx +``` + +In order to allow network routing, users must use the new `expose` section and for the `type`, choose one of the +following: + +* "ingress" (Kubernetes Ingress API) +* "gateway" (Kubernetes Gateway API) +* "none" (no external routing) + +Regardless if one chooses "ingress" or "gateway", the hostname and tls fields will be applied to the selected API. + +#### Robot to Client + +Hub keys were updated and the `values.yaml` was updated accordingly: + +```diff +hub: + auth: +- robotUser: +- robotSecret: ++ clientID: ++ clientSecret: +``` + +#### Improving Security + +##### Default credentials +Several default credentials were removed including keycloak and minio. Users must now specify these credentials when deploying by either providing a username/password directly in the `values.yaml` file or by using an existing secret. The keycloak user `flameuser` is no longer included by default unless explicitly enabled. + +```diff +keycloakx: ++ defaultUserEnabled: false ++ auth: ++ adminUsername: "" ++ adminPassword: "" ++ existingSecret: "" + ++dataStore: + enabled: true + minio: ++ rootUser: "" ++ rootPassword: "" ++ existingSecret: "" +``` + +##### Node VictoriaLogs UI +VictoriaLogs is now the primary application for storing and serving logs from all node related components and services. It is enabled by default, but access to it's included UI is disabled as it is not currently secured behind user authentication. If ingress for the VictoriaLogs UI is enabled, it can be found at `https:///logs/select/vmui` + +```diff ++victorialogs: ++ enabled: true ++ ingress: ++ enabled: false +``` + +#### flame-node-data-store to dataStore +To simplify referencing this subchart in the helper functions, it was given an alias of `dataStore` which should now be used instead + +```diff +- flame-node-data-store: ++ dataStore: + enabled: true +``` + +### Migration Guide + +Adapting previous versions to the current one is very straightforward, the following table shows how values map from +`values.yaml` files from previous versions (i.e. `<0.1.0`) to the current stable version (`0.1.0`): + +| Previous Value | Current Value | Comment | +|----------------------------------------------------------------------------------------------------------|---------------------------------------------|----------------------------------------------------------------------------------------| +| `.global.node.ingress.enabled` == "true"
`.ingress.enabled` == "true" | `.expose.type` == "ingress" | This can also be set to "gateway" if you are using the new Gateway API | +| `.global.node.ingress.enabled` == "false"
`.ingress.enabled` == "false" | `.expose.type` == "none" | | +| `.global.node.ingress.hostname` == "https://your-domain"
`.ingress.hostname` == "https://your-domain" | `.expose.hostname` == "https://your-domain" | | +| `.ingress.annotations` | `.expose.ingress.annotations` | | +| `.ingress.className` | `.expose.ingress.className` | | +| `.ingress.pathType` | `.expose.ingress.pathType` | | +| `.ingress.tlsSecretName` | `.expose.tls.secretName` | | +| `.hub.auth.robotUser` | `.hub.auth.clientID` | | +| `.hub.auth.robotSecret` | `.hub.auth.clientSecret` | | +| `.flame-node-data-store` | `.dataStore` | | +| | `.keycloakx.defaultUserEnabled` | Enable if you want the `flameuser` test user created in your bundled keycloak instance | +| | `.keycloakx.auth` | Enter your admin credentials in these fields | +| | `.dataStore.minio` | If the dataStore is `enabled`, enter your admin credentials here | +| | `.victorialogs.ingress.enabled` | Set to `true` if you want to access the VictoriaLogs UI | +| | `.proxy.existingSecret` | Can now set proxy information using an existing secret |