mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-26 04:58:07 +00:00
Fix HTML validation errors
This commit is contained in:
Billy Tat
+1
-1
@@ -105,7 +105,7 @@ Rancher lets you assign _custom project roles_ to a standard user instead of the
|
||||
|
||||
The following table lists each built-in custom project role available in Rancher and whether it is also granted by the `Owner`, `Member`, or `Read Only` role.
|
||||
|
||||
| Built-in Project Role | Owner | Member<a id="proj-roles"><a/> | Read Only |
|
||||
| Built-in Project Role | Owner | Member<a id="proj-roles"></a> | Read Only |
|
||||
| ---------------------------------- | ------------- | ----------------------------- | ------------- |
|
||||
| Manage Project Members | ✓ | | |
|
||||
| Create Namespaces | ✓ | ✓ | |
|
||||
|
||||
@@ -9,25 +9,25 @@ This FAQ is a work in progress designed to answers the questions our users most
|
||||
|
||||
See [Technical FAQ]({{<baseurl>}}/rancher/v2.0-v2.4/en/faq/technical/), for frequently asked technical questions.
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
**Does Rancher v2.x support Docker Swarm and Mesos as environment types?**
|
||||
|
||||
When creating an environment in Rancher v2.x, Swarm and Mesos will no longer be standard options you can select. However, both Swarm and Mesos will continue to be available as Catalog applications you can deploy. It was a tough decision to make but, in the end, it came down to adoption. For example, out of more than 15,000 clusters, only about 200 or so are running Swarm.
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
**Is it possible to manage Azure Kubernetes Services with Rancher v2.x?**
|
||||
|
||||
Yes.
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
**Does Rancher support Windows?**
|
||||
|
||||
As of Rancher 2.3.0, we support Windows Server 1809 containers. For details on how to set up a cluster with Windows worker nodes, refer to the section on [configuring custom clusters for Windows.]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/windows-clusters/)
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
**Does Rancher support Istio?**
|
||||
|
||||
@@ -35,37 +35,37 @@ As of Rancher 2.3.0, we support [Istio.]({{<baseurl>}}/rancher/v2.0-v2.4/en/clus
|
||||
|
||||
Furthermore, Istio is implemented in our micro-PaaS "Rio", which works on Rancher 2.x along with any CNCF compliant Kubernetes cluster. You can read more about it [here](https://rio.io/)
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
**Will Rancher v2.x support Hashicorp's Vault for storing secrets?**
|
||||
|
||||
Secrets management is on our roadmap but we haven't assigned it to a specific release yet.
|
||||
Secrets management is on our roadmap but we haven't assigned it to a specific release yet.
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
**Does Rancher v2.x support RKT containers as well?**
|
||||
|
||||
At this time, we only support Docker.
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
**Does Rancher v2.x support Calico, Contiv, Contrail, Flannel, Weave net, etc., for embedded and imported Kubernetes?**
|
||||
|
||||
Out-of-the-box, Rancher provides the following CNI network providers for Kubernetes clusters: Canal, Flannel, Calico and Weave (Weave is available as of v2.2.0). Always refer to the [Rancher Support Matrix](https://rancher.com/support-maintenance-terms/) for details about what is officially supported.
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
**Are you planning on supporting Traefik for existing setups?**
|
||||
|
||||
We don't currently plan on providing embedded Traefik support, but we're still exploring load-balancing approaches.
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
**Can I import OpenShift Kubernetes clusters into v2.x?**
|
||||
|
||||
Our goal is to run any upstream Kubernetes clusters. Therefore, Rancher v2.x should work with OpenShift, but we haven't tested it yet.
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
**Are you going to integrate Longhorn?**
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@ weight: 8007
|
||||
|
||||
The Hardening Guide is now located in the main [Security]({{<baseurl>}}/rancher/v2.0-v2.4/en/security/) section.
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
**What are the results of Rancher's Kubernetes cluster when it is CIS benchmarked?**
|
||||
|
||||
|
||||
+2
-2
@@ -59,8 +59,8 @@ When Rancher is installed on an air gapped Kubernetes cluster, there are two rec
|
||||
|
||||
| Configuration | Chart option | Description | Requires cert-manager |
|
||||
| ------------------------------------------ | ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------- |
|
||||
| Rancher Generated Self-Signed Certificates | `ingress.tls.source=rancher` | Use certificates issued by Rancher's generated CA (self signed)<br> This is the **default** and does not need to be added when rendering the Helm template. | yes |
|
||||
| Certificates from Files | `ingress.tls.source=secret` | Use your own certificate files by creating Kubernetes Secret(s). <br> This option must be passed when rendering the Rancher Helm template. | no |
|
||||
| Rancher Generated Self-Signed Certificates | `ingress.tls.source=rancher` | Use certificates issued by Rancher's generated CA (self signed)<br/> This is the **default** and does not need to be added when rendering the Helm template. | yes |
|
||||
| Certificates from Files | `ingress.tls.source=secret` | Use your own certificate files by creating Kubernetes Secret(s). <br/> This option must be passed when rendering the Rancher Helm template. | no |
|
||||
|
||||
# 3. Render the Rancher Helm Template
|
||||
|
||||
|
||||
+1
-1
@@ -24,7 +24,7 @@ The usage below defines rules about what the audit log should record and what da
|
||||
|
||||
| Parameter | Description |
|
||||
| ------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| <a id="audit-level"></a>`AUDIT_LEVEL` | `0` - Disable audit log (default setting).<br/>`1` - Log event metadata.<br/>`2` - Log event metadata and request body.</br>`3` - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same `auditID` value.<br/><br/>See [Audit Level Logging](#audit-log-levels) for a table that displays what each setting logs. |
|
||||
| <a id="audit-level"></a>`AUDIT_LEVEL` | `0` - Disable audit log (default setting).<br/>`1` - Log event metadata.<br/>`2` - Log event metadata and request body.<br/>`3` - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same `auditID` value.<br/><br/>See [Audit Level Logging](#audit-log-levels) for a table that displays what each setting logs. |
|
||||
| `AUDIT_LOG_PATH` | Log path for Rancher Server API. Default path is `/var/log/auditlog/rancher-api-audit.log`. You can mount the log directory to host. <br/><br/>Usage Example: `AUDIT_LOG_PATH=/my/custom/path/`<br/> |
|
||||
| `AUDIT_LOG_MAXAGE` | Defined the maximum number of days to retain old audit log files. Default is 10 days. |
|
||||
| `AUDIT_LOG_MAXBACKUP` | Defines the maximum number of audit log files to retain. Default is 10. |
|
||||
|
||||
@@ -134,7 +134,7 @@ PLUGIN_MIRROR | Docker daemon registry mirror
|
||||
PLUGIN_INSECURE | Docker daemon allows insecure registries
|
||||
PLUGIN_BUILD_ARGS | Docker build args, a comma separated list
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
```yaml
|
||||
# This example shows an environment variable being used
|
||||
@@ -526,7 +526,7 @@ If you need to use security-sensitive information in your pipeline scripts (like
|
||||
|
||||
### Prerequisite
|
||||
Create a secret in the same project as your pipeline, or explicitly in the namespace where pipeline build pods run.
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
>**Note:** Secret injection is disabled on [pull request events](#triggers-and-trigger-rules).
|
||||
|
||||
@@ -637,7 +637,7 @@ stages:
|
||||
|
||||
>**Note:** Rancher sets default compute resources for pipeline steps except for `Build and Publish Images` and `Run Script` steps. You can override the default value by specifying compute resources in the same way.
|
||||
|
||||
### Custom CA
|
||||
### Custom CA
|
||||
|
||||
_Available as of v2.2.0_
|
||||
|
||||
|
||||
+1
-1
@@ -106,7 +106,7 @@ Rancher lets you assign _custom project roles_ to a standard user instead of the
|
||||
|
||||
The following table lists each built-in custom project role available in Rancher and whether it is also granted by the `Owner`, `Member`, or `Read Only` role.
|
||||
|
||||
| Built-in Project Role | Owner | Member<a id="proj-roles"><a/> | Read Only |
|
||||
| Built-in Project Role | Owner | Member<a id="proj-roles"></a> | Read Only |
|
||||
| ---------------------------------- | ------------- | ----------------------------- | ------------- |
|
||||
| Manage Project Members | ✓ | | |
|
||||
| Create Namespaces | ✓ | ✓ | |
|
||||
|
||||
+1
-1
@@ -98,7 +98,7 @@ EKS clusters must have at least one managed node group to be imported into Ranch
|
||||
|
||||
**Result:**
|
||||
|
||||
- Your cluster is registered and assigned a state of **Pending.** Rancher is deploying resources to manage your cluster.</li>
|
||||
- Your cluster is registered and assigned a state of **Pending.** Rancher is deploying resources to manage your cluster.
|
||||
- You can access your cluster after its state is updated to **Active.**
|
||||
- **Active** clusters are assigned two Projects: `Default` (containing the namespace `default`) and `System` (containing the namespaces `cattle-system`, `ingress-nginx`, `kube-public` and `kube-system`, if present).
|
||||
|
||||
|
||||
+3
-3
@@ -12,10 +12,10 @@ The following table lists the permissions required for the vSphere user account:
|
||||
|
||||
| Privilege Group | Operations |
|
||||
|:----------------------|:-----------------------------------------------------------------------|
|
||||
| Datastore | AllocateSpace </br> Browse </br> FileManagement (Low level file operations) </br> UpdateVirtualMachineFiles </br> UpdateVirtualMachineMetadata |
|
||||
| Datastore | AllocateSpace <br/> Browse <br/> FileManagement (Low level file operations) <br/> UpdateVirtualMachineFiles <br/> UpdateVirtualMachineMetadata |
|
||||
| Network | Assign |
|
||||
| Resource | AssignVMToPool |
|
||||
| Virtual Machine | Config (All) </br> GuestOperations (All) </br> Interact (All) </br> Inventory (All) </br> Provisioning (All) |
|
||||
| Virtual Machine | Config (All) <br/> GuestOperations (All) <br/> Interact (All) <br/> Inventory (All) <br/> Provisioning (All) |
|
||||
|
||||
The following steps create a role with the required privileges and then assign it to a new user in the vSphere console:
|
||||
|
||||
@@ -38,7 +38,7 @@ The following steps create a role with the required privileges and then assign i
|
||||
7. Create a new Global Permission. Add the user you created earlier and assign it the role you created earlier. Click **OK**.
|
||||
|
||||
{{< img "/img/rancher/globalpermissionuser.png" "image" >}}
|
||||
|
||||
|
||||
{{< img "/img/rancher/globalpermissionrole.png" "image" >}}
|
||||
|
||||
**Result:** You now have credentials that Rancher can use to manipulate vSphere resources.
|
||||
|
||||
@@ -30,16 +30,16 @@ Fleet comes preinstalled in Rancher v2.5. Users can leverage continuous delivery
|
||||
|
||||
Follow the steps below to access Continuous Delivery in the Rancher UI:
|
||||
|
||||
1. Click **Cluster Explorer** in the Rancher UI.
|
||||
1. Click **Cluster Explorer** in the Rancher UI.
|
||||
|
||||
1. In the top left dropdown menu, click **Cluster Explorer > Continuous Delivery.**
|
||||
|
||||
1. Select your namespace at the top of the menu, noting the following:
|
||||
- By default,`fleet-default` is selected which includes all downstream clusters that are registered through Rancher.
|
||||
- You may switch to `fleet-local`, which only contains the `local` cluster, or you may create your own workspace to which you may assign and move clusters.
|
||||
1. Select your namespace at the top of the menu, noting the following:
|
||||
- By default,`fleet-default` is selected which includes all downstream clusters that are registered through Rancher.
|
||||
- You may switch to `fleet-local`, which only contains the `local` cluster, or you may create your own workspace to which you may assign and move clusters.
|
||||
- You can then manage clusters by clicking on **Clusters** on the left navigation bar.
|
||||
|
||||
1. Click on **Gitrepos** on the left navigation bar to deploy the gitrepo into your clusters in the current workspace.
|
||||
1. Click on **Gitrepos** on the left navigation bar to deploy the gitrepo into your clusters in the current workspace.
|
||||
|
||||
1. Select your [git repository](https://fleet.rancher.io/gitrepo-add/) and [target clusters/cluster group](https://fleet.rancher.io/gitrepo-structure/). You can also create the cluster group in the UI by clicking on **Cluster Groups** from the left navigation bar.
|
||||
|
||||
@@ -71,23 +71,23 @@ The Helm chart in the git repository must include its dependencies in the charts
|
||||
|
||||
# Troubleshooting
|
||||
---
|
||||
* **Known Issue:** Fleet becomes inoperable after a restore using the [backup-restore-operator]({{<baseurl>}}/rancher/v2.5/en/backups/back-up-rancher/#1-install-the-rancher-backup-operator). We will update the community once a permanent solution is in place.
|
||||
* **Known Issue:** Fleet becomes inoperable after a restore using the [backup-restore-operator]({{<baseurl>}}/rancher/v2.5/en/backups/back-up-rancher/#1-install-the-rancher-backup-operator). We will update the community once a permanent solution is in place.
|
||||
|
||||
* **Temporary Workaround:** </br>
|
||||
1. Find the two service account tokens listed in the fleet-controller and the fleet-controller-bootstrap service accounts. These are under the fleet-system namespace of the local cluster. </br>
|
||||
2. Remove the non-existent token secret. Doing so allows for only one entry to be present for the service account token secret that actually exists. </br>
|
||||
3. Delete the fleet-controller Pod in the fleet-system namespace to reschedule. </br>
|
||||
4. After the service account token issue is resolved, you can force redeployment of the fleet-agents. In the Rancher UI, go to **☰ > Cluster Management**, click on **Clusters** page, then click **Force Update**. </br>
|
||||
* **Temporary Workaround:** <br/>
|
||||
1. Find the two service account tokens listed in the fleet-controller and the fleet-controller-bootstrap service accounts. These are under the fleet-system namespace of the local cluster. <br/>
|
||||
2. Remove the non-existent token secret. Doing so allows for only one entry to be present for the service account token secret that actually exists. <br/>
|
||||
3. Delete the fleet-controller Pod in the fleet-system namespace to reschedule. <br/>
|
||||
4. After the service account token issue is resolved, you can force redeployment of the fleet-agents. In the Rancher UI, go to **☰ > Cluster Management**, click on **Clusters** page, then click **Force Update**. <br/>
|
||||
5. If the fleet-agent bundles remain in a `Modified` state after Step 4, update the field `spec.forceSyncGeneration` for the fleet-agent bundle to force re-creation.
|
||||
|
||||
---
|
||||
* **Known Issue:** clientSecretName and helmSecretName secrets for Fleet gitrepos are not included in the backup nor restore created by the [backup-restore-operator]({{<baseurl>}}/rancher/v2.5/en/backups/back-up-rancher/#1-install-the-rancher-backup-operator). We will update the community once a permanent solution is in place.
|
||||
* **Known Issue:** clientSecretName and helmSecretName secrets for Fleet gitrepos are not included in the backup nor restore created by the [backup-restore-operator]({{<baseurl>}}/rancher/v2.5/en/backups/back-up-rancher/#1-install-the-rancher-backup-operator). We will update the community once a permanent solution is in place.
|
||||
|
||||
* **Temporary Workaround:** </br>
|
||||
* **Temporary Workaround:** <br/>
|
||||
By default, user-defined secrets are not backed up in Fleet. It is necessary to recreate secrets if performing a disaster recovery restore or migration of Rancher into a fresh cluster. To modify resourceSet to include extra resources you want to backup, refer to docs [here](https://github.com/rancher/backup-restore-operator#user-flow).
|
||||
|
||||
---
|
||||
|
||||
|
||||
# Documentation
|
||||
|
||||
The Fleet documentation is at [https://fleet.rancher.io/.](https://fleet.rancher.io/)
|
||||
|
||||
@@ -10,25 +10,25 @@ This FAQ is a work in progress designed to answer the questions our users most f
|
||||
|
||||
See [Technical FAQ]({{<baseurl>}}/rancher/v2.5/en/faq/technical/), for frequently asked technical questions.
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
**Does Rancher v2.x support Docker Swarm and Mesos as environment types?**
|
||||
|
||||
When creating an environment in Rancher v2.x, Swarm and Mesos will no longer be standard options you can select. However, both Swarm and Mesos will continue to be available as Catalog applications you can deploy. It was a tough decision to make but, in the end, it came down to adoption. For example, out of more than 15,000 clusters, only about 200 or so are running Swarm.
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
**Is it possible to manage Azure Kubernetes Services with Rancher v2.x?**
|
||||
|
||||
Yes.
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
**Does Rancher support Windows?**
|
||||
|
||||
As of Rancher 2.3.0, we support Windows Server 1809 containers. For details on how to set up a cluster with Windows worker nodes, refer to the section on [configuring custom clusters for Windows.]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/rke-clusters/windows-clusters/)
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
**Does Rancher support Istio?**
|
||||
|
||||
@@ -36,37 +36,37 @@ As of Rancher 2.3.0, we support [Istio.]({{<baseurl>}}/rancher/v2.5/en/istio/)
|
||||
|
||||
Furthermore, Istio is implemented in our micro-PaaS "Rio", which works on Rancher 2.x along with any CNCF compliant Kubernetes cluster. You can read more about it [here](https://rio.io/)
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
**Will Rancher v2.x support Hashicorp's Vault for storing secrets?**
|
||||
|
||||
There is no built-in integration of Rancher and Hashicorp's Vault. Rancher manages Kubernetes and integrates with secrets via the Kubernetes API. Thus in any downstream (managed) cluster, you can use a secret vault of your choice provided it integrates with Kubernetes, including [Vault](https://www.vaultproject.io/docs/platform/k8s).
|
||||
There is no built-in integration of Rancher and Hashicorp's Vault. Rancher manages Kubernetes and integrates with secrets via the Kubernetes API. Thus in any downstream (managed) cluster, you can use a secret vault of your choice provided it integrates with Kubernetes, including [Vault](https://www.vaultproject.io/docs/platform/k8s).
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
**Does Rancher v2.x support RKT containers as well?**
|
||||
|
||||
At this time, we only support Docker.
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
**Does Rancher v2.x support Calico, Contiv, Contrail, Flannel, Weave net, etc., for embedded and registered Kubernetes?**
|
||||
|
||||
Out-of-the-box, Rancher provides the following CNI network providers for Kubernetes clusters: Canal, Flannel, Calico and Weave. Always refer to the [Rancher Support Matrix](https://rancher.com/support-maintenance-terms/) for details about what is officially supported.
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
**Are you planning on supporting Traefik for existing setups?**
|
||||
|
||||
We don't currently plan on providing embedded Traefik support, but we're still exploring load-balancing approaches.
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
**Can I import OpenShift Kubernetes clusters into v2.x?**
|
||||
|
||||
Our goal is to run any upstream Kubernetes clusters. Therefore, Rancher v2.x should work with OpenShift, but we haven't tested it yet.
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
**Are you going to integrate Longhorn?**
|
||||
|
||||
|
||||
@@ -9,7 +9,7 @@ aliases:
|
||||
|
||||
The Hardening Guide is now located in the main [Security]({{<baseurl>}}/rancher/v2.5/en/security/) section.
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
**What are the results of Rancher's Kubernetes cluster when it is CIS benchmarked?**
|
||||
|
||||
|
||||
@@ -52,7 +52,7 @@ These items represent helm repositories, and can be either traditional helm endp
|
||||
|
||||
To add a private CA for Helm Chart repositories:
|
||||
|
||||
- **HTTP-based chart repositories**: You must add a base64 encoded copy of the CA certificate in DER format to the spec.caBundle field of the chart repo, such as `openssl x509 -outform der -in ca.pem | base64 -w0`. Click **Edit YAML** for the chart repo and set, as in the following example:</br>
|
||||
- **HTTP-based chart repositories**: You must add a base64 encoded copy of the CA certificate in DER format to the spec.caBundle field of the chart repo, such as `openssl x509 -outform der -in ca.pem | base64 -w0`. Click **Edit YAML** for the chart repo and set, as in the following example:<br/>
|
||||
```
|
||||
[...]
|
||||
spec:
|
||||
@@ -63,7 +63,7 @@ To add a private CA for Helm Chart repositories:
|
||||
[...]
|
||||
```
|
||||
|
||||
- **Git-based chart repositories**: It is not currently possible to add a private CA. For git-based chart repositories with a certificate signed by a private CA, you must disable TLS verification. Click **Edit YAML** for the chart repo, and add the key/value pair as follows:
|
||||
- **Git-based chart repositories**: It is not currently possible to add a private CA. For git-based chart repositories with a certificate signed by a private CA, you must disable TLS verification. Click **Edit YAML** for the chart repo, and add the key/value pair as follows:
|
||||
```
|
||||
[...]
|
||||
spec:
|
||||
@@ -73,7 +73,7 @@ To add a private CA for Helm Chart repositories:
|
||||
|
||||
> **Note:** Helm chart repositories with authentication
|
||||
>
|
||||
> As of Rancher v2.5.12, a new value `disableSameOriginCheck` has been added to the Repo.Spec. This allows users to bypass the same origin checks, sending the repository Authentication information as a Basic Auth Header with all API calls. This is not recommended but can be used as a temporary solution in cases of non-standard Helm chart repositories such as those that have redirects to a different origin URL.
|
||||
> As of Rancher v2.5.12, a new value `disableSameOriginCheck` has been added to the Repo.Spec. This allows users to bypass the same origin checks, sending the repository Authentication information as a Basic Auth Header with all API calls. This is not recommended but can be used as a temporary solution in cases of non-standard Helm chart repositories such as those that have redirects to a different origin URL.
|
||||
>
|
||||
> To use this feature for an existing Helm chart repository, click <b>⋮ > Edit YAML</b>. On the `spec` portion of the YAML file, add `disableSameOriginCheck` and set it to `true`.
|
||||
>
|
||||
@@ -82,7 +82,7 @@ To add a private CA for Helm Chart repositories:
|
||||
spec:
|
||||
disableSameOriginCheck: true
|
||||
[...]
|
||||
```
|
||||
```
|
||||
|
||||
### Helm Compatibility
|
||||
|
||||
|
||||
+2
-2
@@ -67,8 +67,8 @@ When Rancher is installed on an air gapped Kubernetes cluster, there are two rec
|
||||
|
||||
| Configuration | Chart option | Description | Requires cert-manager |
|
||||
| ------------------------------------------ | ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------- |
|
||||
| Rancher Generated Self-Signed Certificates | `ingress.tls.source=rancher` | Use certificates issued by Rancher's generated CA (self signed)<br> This is the **default** and does not need to be added when rendering the Helm template. | yes |
|
||||
| Certificates from Files | `ingress.tls.source=secret` | Use your own certificate files by creating Kubernetes Secret(s). <br> This option must be passed when rendering the Rancher Helm template. | no |
|
||||
| Rancher Generated Self-Signed Certificates | `ingress.tls.source=rancher` | Use certificates issued by Rancher's generated CA (self signed)<br/> This is the **default** and does not need to be added when rendering the Helm template. | yes |
|
||||
| Certificates from Files | `ingress.tls.source=secret` | Use your own certificate files by creating Kubernetes Secret(s). <br/> This option must be passed when rendering the Rancher Helm template. | no |
|
||||
|
||||
# Helm Chart Options for Air Gap Installations
|
||||
|
||||
|
||||
+1
-1
@@ -25,7 +25,7 @@ The usage below defines rules about what the audit log should record and what da
|
||||
|
||||
| Parameter | Description |
|
||||
| ------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| <a id="audit-level"></a>`AUDIT_LEVEL` | `0` - Disable audit log (default setting).<br/>`1` - Log event metadata.<br/>`2` - Log event metadata and request body.</br>`3` - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same `auditID` value.<br/><br/>See [Audit Level Logging](#audit-log-levels) for a table that displays what each setting logs. |
|
||||
| <a id="audit-level"></a>`AUDIT_LEVEL` | `0` - Disable audit log (default setting).<br/>`1` - Log event metadata.<br/>`2` - Log event metadata and request body.<br/>`3` - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same `auditID` value.<br/><br/>See [Audit Level Logging](#audit-log-levels) for a table that displays what each setting logs. |
|
||||
| `AUDIT_LOG_PATH` | Log path for Rancher Server API. Default path is `/var/log/auditlog/rancher-api-audit.log`. You can mount the log directory to host. <br/><br/>Usage Example: `AUDIT_LOG_PATH=/my/custom/path/`<br/> |
|
||||
| `AUDIT_LOG_MAXAGE` | Defined the maximum number of days to retain old audit log files. Default is 10 days. |
|
||||
| `AUDIT_LOG_MAXBACKUP` | Defines the maximum number of audit log files to retain. Default is 10. |
|
||||
|
||||
@@ -9,7 +9,7 @@ aliases:
|
||||
|
||||
This section describes the permissions required to access Istio features.
|
||||
|
||||
The rancher istio chart installs three `ClusterRoles`
|
||||
The rancher istio chart installs three `ClusterRoles`
|
||||
|
||||
## Cluster-Admin Access
|
||||
|
||||
@@ -34,15 +34,15 @@ Istio creates three `ClusterRoles` and adds Istio CRD access to the following de
|
||||
|
||||
ClusterRole create by chart | Default K8s ClusterRole | Rancher Role |
|
||||
------------------------------:| ---------------------------:|---------:|
|
||||
`istio-admin` | admin| Project Owner |
|
||||
`istio-edit`| edit | Project Member |
|
||||
`istio-view` | view | Read-only |
|
||||
`istio-admin` | admin| Project Owner |
|
||||
`istio-edit`| edit | Project Member |
|
||||
`istio-view` | view | Read-only |
|
||||
|
||||
Rancher will continue to use cluster-owner, cluster-member, project-owner, project-member, etc as role names, but will utilize default roles to determine access. For each default K8s `ClusterRole` there are different Istio CRD permissions and K8s actions (Create ( C ), Get ( G ), List ( L ), Watch ( W ), Update ( U ), Patch ( P ), Delete( D ), All ( * )) that can be performed.
|
||||
Rancher will continue to use cluster-owner, cluster-member, project-owner, project-member, etc as role names, but will utilize default roles to determine access. For each default K8s `ClusterRole` there are different Istio CRD permissions and K8s actions (Create ( C ), Get ( G ), List ( L ), Watch ( W ), Update ( U ), Patch ( P ), Delete( D ), All ( * )) that can be performed.
|
||||
|
||||
|
||||
|CRDs | Admin | Edit | View
|
||||
|CRDs | Admin | Edit | View
|
||||
|----------------------------| ------| -----| -----
|
||||
| <ul><li>`config.istio.io`</li><ul><li>`adapters`</li><li>`attributemanifests`<li>`handlers`</li><li>`httpapispecbindings`</li><li>`httpapispecs`</li><li>`instances`</li><li>`quotaspecbindings`</li><li>`quotaspecs`</li><li>`rules`</lli><li>`templates`</li></ul></ul>| GLW | GLW | GLW
|
||||
|<ul><li>`networking.istio.io`</li><ul><li>`destinationrules`</li><li>`envoyfilters`<li>`gateways`</li><li>`serviceentries`</li><li>`sidecars`</li><li>`virtualservices`</li><li>`workloadentries`</li></ul></ul>| * | * | GLW
|
||||
|<ul><li>`security.istio.io`</li><ul><li>`authorizationpolicies`</li><li>`peerauthentications`<li>`requestauthentications`</li></ul></ul>| * | * | GLW
|
||||
| <ul><li>`config.istio.io`</li><ul><li>`adapters`</li><li>`attributemanifests`</li><li>`handlers`</li><li>`httpapispecbindings`</li><li>`httpapispecs`</li><li>`instances`</li><li>`quotaspecbindings`</li><li>`quotaspecs`</li><li>`rules`</li><li>`templates`</li></ul></ul>| GLW | GLW | GLW
|
||||
|<ul><li>`networking.istio.io`</li><ul><li>`destinationrules`</li><li>`envoyfilters`</li><li>`gateways`</li><li>`serviceentries`</li><li>`sidecars`</li><li>`virtualservices`</li><li>`workloadentries`</li></ul></ul>| * | * | GLW
|
||||
|<ul><li>`security.istio.io`</li><ul><li>`authorizationpolicies`</li><li>`peerauthentications`</li><li>`requestauthentications`</li></ul></ul>| * | * | GLW
|
||||
@@ -133,7 +133,7 @@ PLUGIN_MIRROR | Docker daemon registry mirror
|
||||
PLUGIN_INSECURE | Docker daemon allows insecure registries
|
||||
PLUGIN_BUILD_ARGS | Docker build args, a comma separated list
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
```yaml
|
||||
# This example shows an environment variable being used
|
||||
@@ -518,7 +518,7 @@ If you need to use security-sensitive information in your pipeline scripts (like
|
||||
|
||||
### Prerequisite
|
||||
Create a secret in the same project as your pipeline, or explicitly in the namespace where pipeline build pods run.
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
>**Note:** Secret injection is disabled on [pull request events](#triggers-and-trigger-rules).
|
||||
|
||||
@@ -627,7 +627,7 @@ stages:
|
||||
|
||||
>**Note:** Rancher sets default compute resources for pipeline steps except for `Build and Publish Images` and `Run Script` steps. You can override the default value by specifying compute resources in the same way.
|
||||
|
||||
### Custom CA
|
||||
### Custom CA
|
||||
|
||||
If you want to use a version control provider with a certificate from a custom/internal CA root, the CA root certificates need to be added as part of the version control provider configuration in order for the pipeline build pods to succeed.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user