diff --git a/content/en/docs/Configuration/namespace-management.md b/content/en/docs/Configuration/namespace-management.md index df126aaf..e7bf37d3 100644 --- a/content/en/docs/Configuration/namespace-management.md +++ b/content/en/docs/Configuration/namespace-management.md @@ -5,188 +5,201 @@ description: "Configuring the namespaces accessible and visible to Kiali." ## Introduction -The default Kiali installation (as mentioned in the [Installation guide]({{< ref -"/docs/installation/installation-guide" >}})) gives Kiali access to all -namespaces available in the cluster. +The default Kiali [installation]({{< ref "/docs/installation/installation-guide" >}}) gives Kiali access to all namespaces available in the cluster and will allow all namespaces to be visible. -It is possible to restrict Kiali to a set of desired namespaces by providing a list -of the ones you want, excluding the ones you don't want. You can also filter namespaces by using [Istio's discovery selectors](https://istio.io/latest/docs/reference/config/istio.mesh.v1alpha1/#MeshConfig). You can use a combination of these options together. +It is possible to restrict Kiali so that it can only access a specific set of namespaces by providing [discovery selectors](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#resources-that-support-set-based-requirements) that match those namespaces. Note that Kiali will not use [Istio's discovery selectors](https://istio.io/latest/docs/reference/config/istio.mesh.v1alpha1/#MeshConfig); if Istio has been configured with its own discovery selectors, you will likely want to configure Kiali with the same list of discovery selectors. + +{{% alert color="info" %}} +This documentation makes a distinction between a namespace that is _accessible_ verses _visible_. Kiali can be given access to all namespaces in the cluster, or it can be given restricted permissions so that only certain namespaces are accessible to it. Of the accessible namespaces that Kiali is permitted to see, it can make some or all of them visible to end users. +{{% /alert %}} {{% alert color="warning" %}} -As of Kiali 1.67, the following settings are deprecated: +As of Kiali 1.89, the following settings are no longer supported: +* deployment.accessible_namespaces * api.namespaces.exclude * api.namespaces.include * api.namespaces.label_selector_exclude * api.namespaces.label_selector_include +{{% /alert %}} + +## Cluster Wide Access Mode + +By default, the Kiali Server is given cluster-wide access to all namespaces on the local cluster. This is controlled by the Kiali CR setting `deployment.cluster_wide_access`, which has a default value of `true` when not specified. + +For clusters that have multiple Kiali Servers installed, only one of them may be installed with `deployment.cluster_wide_access` set to `true`. -It is recommended to instead use Istio Discovery Selectors to limit the namespaces in the mesh. +In order to restrict the Kiali Server so that it only has access to certain namespaces on the local cluster, it must first have its cluster-wide access disabled. You do this by setting `deployment.cluster_wide_access` to `false` in the Kiali CR. + +{{% alert color="info" %}} +You can still use discovery selectors (explained below) to limit what Kiali will make visible in the UI while `cluster_wide_access` remains `true`. You would want to do this for the performance benefits it provides the Kiali Server. But with this, the Kiali Server will be granted ClusterRole permissions rather than individual Role permissions per namespace. In other words, it will have _access_ to all namespaces, but will not make all of them _visible_. {{% /alert %}} ## Accessible Namespaces -The "accessible namespaces" setting configures which namespaces are accessible to the Kiali server itself. -The accessible namespaces are defined by a list of regex expressions that match against the namespace names -visible to the Kiali operator. If left unset, the Kiali server will be given access to all namespaces in -the cluster. +With cluster-wide access disabled, the Kiali Server must be told what namespaces are accessible to it. These accessible namespaces are defined by a list of discovery selectors that match namespaces. -The list of accessible namespaces is specified in the Kiali CR via the -`accessible_namespaces` setting, under the main `deployment` section. As an -example, if Kiali is to be installed in the `istio-system` namespace, and is -expected to monitor all namespaces prefixed with `mycorp_`, the setting would -be: +The list of accessible namespaces is specified in the Kiali CR via the `deployment.discovery_selectors.default` setting. As an example, if Kiali is to be installed in the `istio-system` namespace, and is expected to monitor all namespaces with the label "my-mesh", the setting would be: ```yaml spec: deployment: - accessible_namespaces: - - istio-system - - mycorp_.* + cluster_wide_access: false + discovery_selectors: + default: + - matchExpression: + - key: my-mesh + operator: Exists ``` -When you set `accessible_namespaces` to a list of namespaces as the example above illustrates, by default the operator will create a Role for each accessible namespace. Each Role will be assigned to the Kiali Service Account thus providing Kiali permissions to those namespaces. To change that default behavior, `deployment.cluster_wide_access` can be set to `true`. This will tell the operator not to create these Roles and just create a single ClusterRole and assign it to the Kiali Server (see below). +When `cluster_wide_access` is set to `false`, the Kiali Operator will examine the `default` selectors under `spec.deployment.discovery_selectors`, as the example above illustrates. The Kiali Operator will then attempt to find all the namespaces that match the discovery selectors. For each namespace that matches the discovery selectors, the Kiali Operator will create a Role and assign that Role to the Kiali Service Account thus giving Kiali access to those namespaces. These namespaces are therefore called the "accessible namespaces". {{% alert color="info" %}} -Because Kiali server utilizes Kubernetes watches to watch all namespaces in `deployment.accessible_namespaces`, this may cause performance issues. To increase performance you can set `deployment.cluster_wide_access` to `true` when specifying a list of namespaces in `accessible_namespaces`. When you do this, the Kiali Server will be given access to the entire cluster and thus it can use a single cluster watch which increases performance and efficiency. However, you must be aware that when you do this, the Kiali Server will be granted access to the cluster via a ClusterRole - individual Roles will not be created per namespace. The `deployment.accessible_namespaces` will still be used to determine which namespaces to make available to users. +The Kiali Operator will always give the Kiali Server access to the namespace where the Kiali Server is installed and to the Istio control plane namespace (which may be the same namespace), whether those namespaces match a discovery selector or not. When `cluster_wide_access` is `false` and no discovery selectors are defined, the Kiali Server will only be given access to those two namespaces. {{% /alert %}} -{{% alert color="warning" %}} -If you install Kiali using the [Server Helm Chart]({{< ref "/docs/installation/installation-guide/install-with-helm" >}}), these Roles will not be created. This security feature is provided by the operator only, and is one reason why it is recommended to use the operator. The Server Helm Chart is provided only as a convenience. +{{% alert color="info" %}} +Because the Kiali Server utilizes Kubernetes watches to watch all accessible namespaces, this may cause performance issues. To increase performance you can set `deployment.cluster_wide_access` to `true` even when specifying a list of discovery selectors. When you do this, the Kiali Server will be given access to the entire cluster and thus it can use a single cluster watch which increases performance and efficiency. However, you must be aware that when you do this, the Kiali Server will be granted access to the cluster via a ClusterRole - individual Roles will not be created per namespace. The `spec.deployment.discovery_selectors` will still be used to determine which namespaces can be visible to users. {{% /alert %}} -Note that the namespaces declared here (including any regex expressions) are evaluated and discovered by the operator at install time. Namespaces that do not exist at the time of install will not be accessible to Kiali until the operator has a chance to reconcile the Kiali CR. If you enable namespace watching in the operator, this should happen fairly quickly after the new namespace is created. Namespace watching is an advanced feature; see the [FAQ]({{< ref "/docs/faq/installation" >}}) describing the operator WATCHES_FILE environment variable. Adding the new namespace to the list of `accessible_namespaces` will also trigger the operator to reconcile the Kiali CR. When the operator reconciles the Kiali CR, the necessary Role will be created giving the Kiali Server access to the new namespace. - {{% alert color="warning" %}} -As you can see in the example, the namespace where Kiali is installed must be listed as accessible (often, but not always, this is the same namespace as the Istio control plane namespace). If it is not in the list, it will be added for you by the operator. +If you install Kiali using the [Server Helm Chart]({{< ref "/docs/installation/installation-guide/install-with-helm" >}}), these Roles will not be created; so cluster-wide access must be enabled. This security feature is provided by the operator only, and is one reason why it is recommended to use the operator. The Server Helm Chart is provided only as a convenience. {{% /alert %}} -As mentioned earlier, if you leave `accessible_namespaces` unset, this denotes that the Kiali server is given access to all namespaces in the cluster, including any namespaces that are created in the future. If you do this, individual Roles are not created per namespace; instead a single ClusterRole is created and assigned to the Kiali Service Account thus providing Kiali access to all namespaces in the cluster. - -```yaml -spec: - deployment: {} -``` - {{% alert color="warning" %}} -If you install the operator using the [Helm Charts]({{< ref "/docs/installation/installation-guide/install-with-helm#install-with-operator" >}}), to be able to use this default `accessible_namespaces` behavior, you must specify the `--set clusterRoleCreator=true` flag when invoking `helm install`. +If you install the Kiali Operator using the [Operator Helm Chart]({{< ref "/docs/installation/installation-guide/install-with-helm#install-with-operator" >}}), to be able to use `cluster_wide_access=true`, you must specify the `--set clusterRoleCreator=true` flag when invoking `helm install`. {{% /alert %}} -When installing multiple Kiali instances into a single cluster, -`accessible_namespaces` must be mutually exclusive. In other words, a namespace -set must be matched by only one Kiali CR. Regular expressions must not have -overlapping patterns. - {{% alert color="warning" %}} -A cluster can have at most one Kiali instance with `accessible_namespaces` unset. +When installing multiple Kiali instances into a single cluster, `deployment.discovery_selectors.default` must be mutually exclusive. In other words, a namespace must be matched by discovery selectors defined in a single Kiali CR. {{% /alert %}} ## Istio Discovery Selectors -In Istio's [MeshConfig](https://istio.io/latest/docs/reference/config/istio.mesh.v1alpha1/#MeshConfig), you can provide a list of discovery selectors that Istio will consider when processing namespaces. The Kiali server will also utilize these same discovery selectors when determining which namespaces to make available to users. Therefore, these discovery selectors work in conjunction with the `accessible_namespaces` setting. The `accessible_namespaces` setting dictates which namespaces are _accessible_ to the Kiali Server, and hence to users of Kiali. The Istio discovery selectors tell Kiali to make _available_ to users those namespaces within the `accessible_namespaces` list. So discovery selectors are a subset of `accessible_namespaces`. +In Istio's [MeshConfig](https://istio.io/latest/docs/reference/config/istio.mesh.v1alpha1/#MeshConfig), a list of discovery selectors can be configured. These Istio discovery selectors define the namespaces that Istio will consider "in the mesh." (see [this blog post](https://istio.io/v1.13/blog/2021/discovery-selectors/) for details). These Istio discovery selectors are utilized only by Istio; they will be ignored by Kiali. -{{% alert color="info" %}} -You must make sure you configure `accessible_namespaces` with a list of namespaces that are equal to, or are a superset of, the namespaces that result from evaluating the Istio discovery selectors. -{{% /alert %}} +## Operator Namespace Watching -## Included Namespaces - -{{% alert color="warning" %}} -This feature is deprecated as of 1.67. It is recommended to instead use Istio Discovery Selectors. -{{% /alert %}} - -When `accessible_namespaces` is unset, you can still limit the namespaces a user will see in Kiali. The `api.namespaces.include` setting allows you to configure the subset of namespaces that Kiali will show the user. This list is specified in a way similar to `accessible_namespaces`, as a list of namespaces that can include regex patterns. The difference is that this list is processed by the server, not the operator, each time the list of namespaces needs to be obtained by Kiali. This means it will handle namespaces that exist when Kiali is installed, or namespaces created later. +Note that the discovery selectors are evaluated by the Kiali Operator at install time when deciding which namespaces should be accessible (and thus which Roles to create). Namespaces that do not exist at the time of install will not be accessible to Kiali until the operator has a chance to reconcile the Kiali CR. There are several ways in which the operator can be told to reconcile a Kiali CR in order to determine the new set of accessible namespaces. +1. You can ask that the Kiali Operator periodically reconcile the Kiali CR on a fixed schedule. See the [Ansible Operator SDK documentation describing the reconcile-period annotation](https://sdk.operatorframework.io/docs/building-operators/ansible/reference/advanced_options/#ansiblesdkoperatorframeworkioreconcile-period-custom-resource-annotation). In short, you can have the Kiali Operator periodically reconcile a Kiali CR by setting the `ansible.sdk.operatorframework.io/reconcile-period` annotation on the Kiali CR. For example, to reconcile this Kiail CR every 60 seconds: ```yaml -spec: - api: - namespaces: - include: - - istio-system - - mycorp_.* - deployment: {} +metadata: + kind: Kiali + annotations: + ansible.sdk.operatorframework.io/reconcile-period: 60s +``` +2. Modifying the `deployment.discovery_selectors.default` list of discovery selectors will automatically trigger the Kiali Operator to reconcile a Kiali CR and discover new namespaces. In fact, touching any `spec` field in the Kiali CR will trigger a reconciliation of the Kiali CR. +3. Similar to the above, touching any annotation on the Kiali CR will also trigger a reconciliation. One suggestion is to dedicate an annotation whose purpose is solely to trigger operator reconcilations. For example, add or modify the "trigger-reconcile" annotation on the Kiali CR to trigger the operator to run a reconcilation on that Kiali CR: +```sh +kubectl annotate kiali my-kiali-cr --namespace istio-system --overwrite trigger-reconcile="$(date)" ``` +4. The Kiali Operator can be enabled to watch for namespaces getting created in the cluster. When new namespaces are created, the Kiali Operator will detect this and will then attempt to reconcile all Kiali CRs in the cluster. To enable operator namespace watching, see the [FAQ]({{< ref "/docs/faq/installation" >}}) describing the operator WATCHES_FILE environment variable. Note that on clusters with large numbers of namespaces that get created, enabling this namespace watching feature can cause the operator to consume alot of CPU, so you may not wish to use this method. -{{% alert color="info" %}} -The `api.namespaces.include` setting is ignored if `accessible_namespaces` is set. -{{% /alert %}} +Once the Kiali Operator is triggered to reconcile a Kiali CR, the operator will create the necessary Roles for all accessible namespaces, giving the Kiali Server access to any new namespaces that have been created since the last reconciliation. -{{% alert color="info" %}} -The `api.namespaces.include` will implicitly include the control plane namespace (e.g. `istio-system`) even if you do not explicitly specify it in the list. -{{% /alert %}} +## Multi-Cluster Environments -Note that this setting is merely a filter and does not provide security in any way. +The Kiali CR `deployment.discover_selectors` section supports multi-cluster configurations. -## Excluded Namespaces +The `default` discovery selectors define the namespaces on the local cluster that Kiali will have access to (as explained above). These namespaces are made visible to Kiali users. -{{% alert color="warning" %}} -This feature is deprecated as of 1.67. It is recommended to instead use Istio Discovery Selectors. -{{% /alert %}} +It is assumed Kiali will have access to the same set of namespaces on the remote clusters as well. So Kiali will make those remote namespaces visible to users. However, if a remote cluster has a different set of namespaces that should be visible to Kiali users, you can set discovery selector `overrides` in `deployment.discovery_selectors` to match those remote namespaces. -The `api.namespaces.exclude` setting configures namespaces to exclude from being shown to the user. This setting can be used both when `accessible_namespaces` is unset or set to an explicit list of namespaces. It can also be used regardless of whether `api.namespaces.include` is defined. The exclude filter has precedence - if a namespace matches any regex pattern defined for `api.namespaces.exclude`, it will not be shown in Kiali. Like `api.namespaces.include`, the exclude setting is only a filter and does not provide security in any way. +{{% alert color="info" %}} +Each remote cluster `overrides` section completely overrides the default discovery selectors. That is to say, if a remote cluster has discovery selector overrides defined, only those selectors are used to determine which remote namespaces are to be visible to users. The `default` discovery selectors will not be used for a particular remote cluster when `overrides` are defined for that remote cluster. +{{% /alert %}} -For example, if the `accessible_namespaces` configuration includes `mycorp_.*` but it is not desirable to see test namespaces, the following configuration can be used: +Here is an example of defining discovery selectors for a remote cluster: ```yaml spec: - api: - namespaces: - exclude: - - mycorp_test.* deployment: - accessible_namespaces: - - istio-system - - mycorp_.* + cluster_wide_access: false + discovery_selectors: + # define accessible namespaces on the local namespace + default: + - matchExpression: + - key: my-mesh + operator: Exists + overrides: + # My remote cluster has a different set of namespaces + my-remote-cluster: + - matchLabels: + org: production + - matchExpression: + - key: region + operator: In + values: ["east"] ``` -{{% alert color="info" %}} -You cannot exclude the control plane namespace. If you specify it in `api.namespaces.exclude`, it will be ignored. -{{% /alert %}} - -## Namespace Selectors - -{{% alert color="warning" %}} -This feature is deprecated as of 1.67. It is recommended to instead use Istio Discovery Selectors. -{{% /alert %}} - -In addition to the Include and Exclude lists (as explained above), Kiali supports optional Kubernetes label selectors for both including and excluding namespaces. - -The include label selector is defined in the Kiali CR setting `api.namespaces.label_selector_include`. - -The exclude label selector is defined in the Kiali CR setting `api.namespaces.label_selector_exclude`. - -The example below selects all namespaces that have a label `kiali-enabled: true`: +You can define overrides for multiple remote clusters: ```yaml spec: - api: - namespaces: - label_selector_include: kiali-enabled=true - deployment: {} + deployment: + cluster_wide_access: false + discovery_selectors: + default: + - matchLabels: + region: south + overrides: + cluster1: + - matchLabels: + region: east + cluster2: + - matchLabels: + region: west + cluster3: + - matchLabels: + region: north ``` -The example below hides all namespaces that have a label `infrastructure: system`: +## Discovery Selectors -```yaml -spec: - api: - namespaces: - label_selector_exclude: infrastructure=system -``` +The `default` and `overrides` discovery selectors are processed in the same manner. They follow the same semantics as Istio as described in the [Istio discoverySelectors documentation](https://istio.io/latest/docs/reference/config/istio.mesh.v1alpha1/#MeshConfig) (with one caveat: when `deployment.cluster_wide_access` is `false`, an empty list of discovery selectors does not mean all namespaces will be accessible - only the Istio control plane namespace and the Kiali deployment namespace will be accessible in this case). -### Important Note About `label_selector_include` +In short, the `default` discovery selectors and each remote cluster `overrides` are lists of equality-based and set-based label selectors, with each item in a list being disjunctive (that is, match results from each selector item in a selector list are OR'ed together). -It is very important to understand how the `api.namespaces.label_selector_include` setting is used when `deployment.accessible_namespaces` is set to an explicit list of namespaces versus when it is unset. +Each discovery selector list item itself can consist of one `matchLabels`, one `matchExpressions`, or both. A `matchLabels` can match one or more labels; a `matchExpressions` can match one or more expressions. All results within a single discovery selector list item are AND'ed together (that is to say, a namespace must match all label selector conditions in order for that namespace to be selected by that label selector). -When `accessible_namespaces` is unset then `label_selector_include` simply provides a filter just like `api.namespaces.include`. The difference is that `label_selector_include` filters by namespace label whereas `include` filters by namespace name. Thus, `label_selector_include` provides an additional way to limit which namespaces the Kiali user will see when `accessible_namespaces` is unset. +For details on equality-based and set-based selector syntax and semantics, see the [Kubernetes documentation](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors). -It is recommended to leave `label_selector_include` unset when `accessible_namespaces` is set to an explicit list of namespaces. This is because the operator adds the configured label (name and value) to each namespace defined by `accessible_namespaces`. This allows the Kiali code to use the `label_selector_include` value to easily select all of the `accessible_namespaces`. Unless you have a good reason to customize, the default value is highly recommended in this scenario. +Below are a couple of examples to help you understand these semantics. -{{% alert color="warning" %}} -If Kiali is installed via the Server Helm Chart, labels are not added to the accessible namespaces. The user must ensure `api.namespaces.label_selector_include` (if defined) selects all namespaces declared in `accessible_namespaces` (when unset). It is a user-error if this is not configured correctly. -{{% /alert %}} +This defines a discovery selector list that contains a single label selector that consists of one equality-based selector and one set-based selector. The namespaces that match this discovery selector are those that have a `env=production` label AND a `org=frontdesk` label AND a `app=ticketing` label AND a `color=blue` label: -For further information on how this `api.namespaces.label_selector_include` interacts with `deployment.accessible_namespaces` read the [Kiali CR Reference documentation](/docs/configuration/kialis.kiali.io/#.spec.api.namespaces.label_selector_include). +```yaml +discovery_selectors: + default: + - matchLabels: + env: production + org: frontdesk + matchExpressions: + - key: app + operator: In + values: ["ticketing"] + - key: color + operator: In + values: ["blue"] +``` -## Soft Multi-Tenancy +Suppose we want to also make accessible all namespaces that have the label `region=east`. We add another discover selector to the list: -When deploying multiple control planes in the same cluster, the `label_selector_include`'s value must be unique to each control plane. This allows each Kiali instance to select only the namespaces relevant to each control plane. Thus you can have multiple control planes in the same cluster, with each control plane having its own Kiali instance. In this "soft-multitenancy" mode, `deployment.accessible_namespaces` is typically set to an explicit set of namespaces. In that case, you do not have to do anything with this `label_selector_include` because the default value of `label_selector_include` is `kiali.io/member-of: `. If you set your own Kiali instance name in the Kiali CR (i.e. you set `deployment.instance_name` to something other than `kiali`), then the default will be `kiali.io/.member-of: `. +```yaml +discovery_selectors: + default: + - matchLabels: + region: east + - matchLabels: + env: production + org: frontdesk + matchExpressions: + - key: app + operator: In + values: ["ticketing"] + - key: color + operator: In + values: ["blue"] +``` +Now all the same namespaces that matched before are also matched. But in addition, all namespaces that simply have a label `region=east` will also match. This is because both label selectors in the list are OR'ed together. diff --git a/content/en/docs/FAQ/general.md b/content/en/docs/FAQ/general.md index 1db93689..4bd960f9 100644 --- a/content/en/docs/FAQ/general.md +++ b/content/en/docs/FAQ/general.md @@ -277,13 +277,11 @@ See [here](https://github.com/kiali/kiali/blob/master/LICENSE) for the Kiali lic ### Why isn't my namespace in the Namespace Selection dropdown? -When deploying Kiali with the Kiali operator, by default some namespaces are [excluded](https://github.com/kiali/kiali-operator/blob/v1.33/roles/default/kiali-deploy/defaults/main.yml#L24-L28) from the list of namespaces provided by the API and UI. Kiali filters out these namespaces and you will not see them in the Namespace Selection dropdown. [You can adjust which namespaces are excluded]({{< relref "../Configuration/namespace-management/#excluded-namespaces" >}}) by setting the `spec.api.namespaces.exclude` field on the Kiali CR. +Kiali can be told to restrict the namespaces users can see via the Kiali CR `spec.deployment.discovery_selectors` field. If there are no discovery selectors defined, Kiali will allow all namespaces _unless_ `deployment.cluster_wide_access` is false, in which case only Kiali's own namespace and the Istio control plane namespace will be accessible. If a namespace does not match one of the discovery selectors defined in the Kiali CR `spec.deployment.discovery_selectors` field at the time Kiali is installed by the operator it will not be visible in the Namespace Selection dropdown; if a new namespace is created after Kiali is installed and that namespace matches one of the discovery selectors, it will only be visible in the Namespace Selection dropdown after the operator creates the necessary Roles for the Kiali Server and restarts the Kiali Server pod (see [Operator Namespace Watching]({{< ref "/docs/configuration/namespace-management#operator-namespace-watching" >}})). See the [Namespace Management]({{< ref "/docs/configuration/namespace-management" >}}) documentation for more information. -In addition, you must ensure that Kiali has access to the namespaces you are interested in by setting the `spec.deployment.accessible_namespaces` field on the Kiali CR accordingly. Setting `spec.api.namespaces.exclude` alone does not give Kiali access to the namespaces. See the [Namespace Management]({{< ref "/docs/configuration/namespace-management" >}}) guide for more information. +Note that Istio has its own set of optional discovery selectors that can be configured in the Istio MeshConfig `discoverySelectors` field, but these Istio discovery selectors are ignored by Kiali. -Kiali also [caches namespaces](/docs/configuration/kialis.kiali.io/#.spec.kubernetes_config.cache_token_namespace_duration) by default for [10 seconds](https://github.com/kiali/kiali-operator/blob/76a9eac29fb942f199db1d0233c5135049d1f1b1/crd-docs/cr/kiali.io_v1alpha1_kiali.yaml#L397). If the cache is enabled, it might take up to the `spec.kubernetes_config.cache_token_namespace_duration` in order for a newly added namespace to be seen by Kiali. - -Finally, Kiali utilizes the Istio MeshConfig setting `discoverySelectors` - any namespace that does not match the discoverySelectors will not be available to Kiali users. +Kiali also [caches namespaces](/docs/configuration/kialis.kiali.io/#.spec.kubernetes_config.cache_token_namespace_duration) by default for [10 seconds](https://github.com/kiali/kiali-operator/blob/v1.88.0/crd-docs/cr/kiali.io_v1alpha1_kiali.yaml#L447). Therefore, it might take up to the number of seconds specified by `spec.kubernetes_config.cache_token_namespace_duration` in order for a newly added namespace to be seen by Kiali. ### Workload "is not found as" messages diff --git a/content/en/docs/FAQ/installation.md b/content/en/docs/FAQ/installation.md index b123c7d3..f5f3a5b8 100644 --- a/content/en/docs/FAQ/installation.md +++ b/content/en/docs/FAQ/installation.md @@ -6,9 +6,9 @@ description: "Questions about Kiali installation options or issues." ### Operator fails due to `cannot list resource "clusterroles"` error When the Kiali Operator installs a Kiali Server, the Operator will assign the Kiali Server the proper roles/rolebindings so the Kiali Server can access the appropriate namespaces. -The Kiali Operator will check to see if the Kiali CR setting `deployment.accessible_namespaces` is unset. If it is, this means the Kiali Server is to be given access to all namespaces in the cluster, including namespaces that will be created in the future. In this case, the Kiali Operator will create and assign ClusterRole/ClusterRoleBinding resources to the Kiali Server. But in order to do this, the Kiali Operator must itself be given permission to create those ClusterRole and ClusterRoleBinding resources. When you install the Kiali Operator via OLM, these permissions are automatically granted. However, if you installed the Kiali Operator with the [Operator Helm Chart](https://kiali.org/helm-charts/index.yaml), and if you did so with the value [`clusterRoleCreator`](https://github.com/kiali/helm-charts/blob/v1.25.0/kiali-operator/values.yaml#L33-L36) -set to `false` then the Kiali Operator will not be given permission to create cluster roles. In this case, you will be unable to install a Kiali Server if your Kiali -CR does not have `deployment.accessible_namespaces` set to a list of namespaces. - you will get an error similar to this: + +The Kiali Operator will check to see if the Kiali CR setting `deployment.cluster_wide_access` is set to `true` (which is the default value if it is unset). If it is, this means the Kiali Server is to be given access to all namespaces in the cluster, including namespaces that will be created in the future. In this case, the Kiali Operator will create and assign ClusterRole/ClusterRoleBinding resources to the Kiali Server. But in order to be able to do this, the Kiali Operator must itself be given permission to create those ClusterRole and ClusterRoleBinding resources. When you install the Kiali Operator via OLM, these permissions are automatically granted. However, if you installed the Kiali Operator with the [Operator Helm Chart](https://kiali.org/helm-charts/index.yaml), and if you did so with the value [`clusterRoleCreator`](https://github.com/kiali/helm-charts/blob/v1.88.0/kiali-operator/values.yaml#L41-L45) +set to `false` then the Kiali Operator will not be given permission to create cluster roles. In this case, you will be unable to install a Kiali Server if your Kiali CR does not have `deployment.cluster_wide_access` set to `true` (and, again, this is the default if unspecified). You will get an error similar to this: ``` Failed to list rbac.authorization.k8s.io/v1, Kind=ClusterRole: @@ -18,7 +18,7 @@ cannot list resource "clusterroles" in API group "rbac.authorization.k8s.io" at the cluster scope ``` -Thus, if you do not give the Kiali Operator the permission to create cluster roles, you must tell the Operator which specific namespaces the Kiali Server can access. When specific namespaces are specified in `deployment.accessible_namespaces`, the Kiali Operator will create Role and RoleBindings (not the "Cluster" kinds) and assign them to the Kiali Server. +Thus, if you do not give the Kiali Operator the permission to create cluster roles, you must tell the Operator which specific namespaces the Kiali Server can access. When specific namespaces are specified in `deployment.discovery_selectors.default`, the Kiali Operator will create Role and RoleBindings (not the "Cluster" kinds) and assign them to the Kiali Server. ### What values can be set in the Kiali CR? @@ -61,8 +61,7 @@ OPERATOR_NAMESPACE="$(kubectl get deployments --all-namespaces | grep kiali-ope - `ALLOW_AD_HOC_KIALI_NAMESPACE`: must be `true` or `false`. If `true`, the operator will be allowed to install the Kiali Server in any namespace, regardless of which namespace the Kiali CR is created. If `false`, the operator will only install the Kiali Server in the same namespace where the Kiali CR is created - any attempt to do otherwise will cause the operator to abort the Kiali Server installation. - `ALLOW_AD_HOC_KIALI_IMAGE`: must be `true` or `false`. If `true`, the operator will be allowed to install the Kiali Server with a custom container image as defined in the Kiali CR's `spec.deployment.image_name` and/or `spec.deployment.image_version`. If `false`, the operator will only install the Kiali Server with the default image. If a Kiali CR is created with `spec.deployment.image_name` or `spec.deployment.image_version` defined, the operator will abort the Kiali Server installation. - `ALLOW_SECURITY_CONTEXT_OVERRIDE`: must be `true` or `false`. If `true`, the operator will be allowed to install the Kiali Server container with a fully customizable securityContext as defined by the user in the Kial CR. If `false`, the operator will only allow the user to add settings to the securityContext; any attempt to override the default settings in the securityContext will be ignored. -- `ALLOW_ALL_ACCESSIBLE_NAMESPACES`: must be `true` or `false`. If `true`, the operator will allow the user to configure Kiali to access all namespaces in the cluster by not requiring the Kiali CR setting `spec.deployment.accessible_namespaces` to be set to a list of namespaces. If false, the Kiali CR must specify a specific list of namespace names. -- `ACCESSIBLE_NAMESPACES_LABEL`: must be an empty string (`""`) or a label name (e.g. `myLabelName`) or a label name and value (e.g. `myLabelName=myLabelValue`). If just a label name is specified, the label value will default to the value in the Kiali CR `spec.istio_namespace` setting. When not an empty string, this will instruct the operator to restrict the namespaces that a user can add to the Kiali CR `spec.deployment.accessible_namespaces` setting. Only namespaces that have the given label name and value will be permitted in the Kiali CR `spec.deployment.accessible_namespaces` setting. Any namespace not labeled properly but specified in `spec.deployment.accessible_namespaces` will cause the operator to abort the Kiali installation. +- `ALLOW_ALL_ACCESSIBLE_NAMESPACES`: must be `true` or `false`. If `true`, the operator will allow the user to configure Kiali to access all namespaces in the cluster (i.e. will allow a Kiali CR to have `spec.deployment.cluster_wide_access` set to `true`). If `false`, all Kiali CRs must set `spec.deployment.cluster_wide_access` to `false`. - `ANSIBLE_DEBUG_LOGS`: must be `true` or `false`. When `true`, turns on debug logging within the Operator SDK. For details, see the [docs here](https://sdk.operatorframework.io/docs/building-operators/ansible/development-tips/#viewing-the-ansible-logs). - `ANSIBLE_VERBOSITY_KIALI_KIALI_IO`: Controls how verbose the operator logs are - the higher the value the more output is logged. For details, see the [docs here](https://sdk.operatorframework.io/docs/building-operators/ansible/reference/advanced_options/#ansible-verbosity). - `ANSIBLE_CONFIG`: must be `/etc/ansible/ansible.cfg` or `/opt/ansible/ansible-profiler.cfg`. If set to `/opt/ansible/ansible-profiler.cfg` a profiler report will be dumped in the operator logs after each reconciliation run. diff --git a/content/en/docs/Installation/installation-guide/creating-updating-kiali-cr.md b/content/en/docs/Installation/installation-guide/creating-updating-kiali-cr.md index ef6a43df..9416229f 100644 --- a/content/en/docs/Installation/installation-guide/creating-updating-kiali-cr.md +++ b/content/en/docs/Installation/installation-guide/creating-updating-kiali-cr.md @@ -88,7 +88,7 @@ described in the pages of the [Installation]({{< relref "../" >}}) and documentation. For a complete list, see the [Kiali CR Reference](/docs/configuration/kialis.kiali.io). {{% alert color="danger" %}} -It is important to understand the `spec.deployment.accessible_namespaces` setting in the CR. See the +It is important to understand the `spec.deployment.cluster_wide_access` setting in the CR. See the [Namespace Management page]({{< ref "/docs/configuration/namespace-management" >}}) for more information. {{% /alert %}} diff --git a/content/en/docs/Installation/installation-guide/example-install.md b/content/en/docs/Installation/installation-guide/example-install.md index 3eabd781..1c9ae174 100644 --- a/content/en/docs/Installation/installation-guide/example-install.md +++ b/content/en/docs/Installation/installation-guide/example-install.md @@ -58,7 +58,11 @@ spec: auth: strategy: "token" deployment: - accessible_namespaces: ["bookinfo"] + cluster_wide_access: false + discovery_selectors: + default: + - matchLabels: + kubernetes.io/metadata.name: bookinfo view_only_mode: false server: web_root: "/kiali" @@ -100,17 +104,17 @@ $ kubectl get kiali kiali -n istio-system -o jsonpath='{.status}' | jq } ], "deployment": { - "accessibleNamespaces": "bookinfo,istio-system", + "discoverySelectorNamespaces": "bookinfo,istio-system", "instanceName": "kiali", "namespace": "istio-system" }, "environment": { "isKubernetes": true, - "kubernetesVersion": "1.20.2", - "operatorVersion": "v1.41.0" + "kubernetesVersion": "1.28.0", + "operatorVersion": "v1.88.0" }, "progress": { - "duration": "0:00:20", + "duration": "0:00:14", "message": "7. Finished all resource creation" } } @@ -148,7 +152,11 @@ spec: auth: strategy: "anonymous" deployment: - accessible_namespaces: ["bookinfo"] + cluster_wide_access: false + discovery_selectors: + default: + - matchLabels: + kubernetes.io/metadata.name: bookinfo view_only_mode: true instance_name: "kialianon" server: