mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-05-05 12:43:16 +00:00
Add version-2.7 docs
This commit is contained in:
Billy Tat
@@ -0,0 +1,59 @@
|
||||
---
|
||||
title: API Keys
|
||||
---
|
||||
|
||||
## API Keys and User Authentication
|
||||
|
||||
If you want to access your Rancher clusters, projects, or other objects using external applications, you can do so using the Rancher API. However, before your application can access the API, you must provide the app with a key used to authenticate with Rancher. You can obtain a key using the Rancher UI.
|
||||
|
||||
An API key is also required for using Rancher CLI.
|
||||
|
||||
API Keys are composed of four components:
|
||||
|
||||
- **Endpoint:** This is the IP address and path that other applications use to send requests to the Rancher API.
|
||||
- **Access Key:** The token's username.
|
||||
- **Secret Key:** The token's password. For applications that prompt you for two different strings for API authentication, you usually enter the two keys together.
|
||||
- **Bearer Token:** The token username and password concatenated together. Use this string for applications that prompt you for one authentication string.
|
||||
|
||||
:::note
|
||||
|
||||
Users may opt to enable [token hashing](../about-the-api/api-tokens.md).
|
||||
|
||||
:::
|
||||
|
||||
## Creating an API Key
|
||||
|
||||
1. Select **User Avatar > Account & API Keys** from upper right corner.
|
||||
|
||||
2. Click **Create API Key**.
|
||||
|
||||
3. **Optional:** Enter a description for the API key and select an expiration period or a scope. We recommend setting an expiration date.
|
||||
|
||||
The API key won't be valid after expiration. Shorter expiration periods are more secure.
|
||||
|
||||
Expiration period will be bound by `v3/settings/auth-token-max-ttl-minutes`. If it exceeds the max-ttl, API key will be created with max-ttl as the expiration period.
|
||||
|
||||
A scope will limit the API key so that it will only work against the Kubernetes API of the specified cluster. If the cluster is configured with an Authorized Cluster Endpoint, you will be able to use a scoped token directly against the cluster's API without proxying through the Rancher server. See [Authorized Cluster Endpoints](../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-authorized-cluster-endpoint) for more information.
|
||||
|
||||
4. Click **Create**.
|
||||
|
||||
**Step Result:** Your API Key is created. Your API **Endpoint**, **Access Key**, **Secret Key**, and **Bearer Token** are displayed.
|
||||
|
||||
Use the **Bearer Token** to authenticate with Rancher CLI.
|
||||
|
||||
5. Copy the information displayed to a secure location. This information is only displayed once, so if you lose your key, you'll have to make a new one.
|
||||
|
||||
## What's Next?
|
||||
|
||||
- Enter your API key information into the application that will send requests to the Rancher API.
|
||||
- Learn more about the Rancher endpoints and parameters by selecting **View in API** for an object in the Rancher UI.
|
||||
- API keys are used for API calls and [Rancher CLI](../../pages-for-subheaders/cli-with-rancher.md).
|
||||
|
||||
## Deleting API Keys
|
||||
|
||||
If you need to revoke an API key, delete it. You should delete API keys:
|
||||
|
||||
- That may have been compromised.
|
||||
- That have expired.
|
||||
|
||||
To delete an API, select the stale key and click **Delete**.
|
||||
@@ -0,0 +1,51 @@
|
||||
---
|
||||
title: Managing Cloud Credentials
|
||||
---
|
||||
|
||||
When you create a cluster [hosted by an infrastructure provider](../../pages-for-subheaders/use-new-nodes-in-an-infra-provider.md), [node templates](../../pages-for-subheaders/use-new-nodes-in-an-infra-provider.md#node-templates) are used to provision the cluster nodes. These templates use Docker Machine configuration options to define an operating system image and settings/parameters for the node.
|
||||
|
||||
Node templates can use cloud credentials to access the credential information required to provision nodes in the infrastructure providers. The same cloud credential can be used by multiple node templates. By using a cloud credential, you do not have to re-enter access keys for the same cloud provider. Cloud credentials are stored as Kubernetes secrets.
|
||||
|
||||
Cloud credentials are only used by node templates if there are fields marked as `password`. The default `active` node drivers have their account access fields marked as `password`, but there may be some `inactive` node drivers, which are not using them yet. These node drivers will not use cloud credentials.
|
||||
|
||||
You can create cloud credentials in two contexts:
|
||||
|
||||
- [During creation of a node template](../../pages-for-subheaders/use-new-nodes-in-an-infra-provider.md#node-templates) for a cluster.
|
||||
- In the **User Settings**
|
||||
|
||||
All cloud credentials are bound to the user profile of who created it. They **cannot** be shared across users.
|
||||
|
||||
## Creating a Cloud Credential from User Settings
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Click **Cloud Credentials**.
|
||||
1. Click **Create**.
|
||||
1. Click a cloud credential type. The values of this dropdown is based on the `active` [node drivers](../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/about-provisioning-drivers/manage-node-drivers.md) in Rancher.
|
||||
1. Enter a name for the cloud credential.
|
||||
1. Based on the selected cloud credential type, enter the required values to authenticate with the infrastructure provider.
|
||||
1. Click **Create**.
|
||||
|
||||
**Result:** The cloud credential is created and can immediately be used to [create node templates](../../pages-for-subheaders/use-new-nodes-in-an-infra-provider.md#node-templates).
|
||||
|
||||
## Updating a Cloud Credential
|
||||
|
||||
When access credentials are changed or compromised, updating a cloud credential allows you to rotate those credentials while keeping the same node template.
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Click **Cloud Credentials**.
|
||||
1. Choose the cloud credential you want to edit and click the **⋮ > Edit Config**.
|
||||
1. Update the credential information and click **Save**.
|
||||
|
||||
**Result:** The cloud credential is updated with the new access credentials. All existing node templates using this cloud credential will automatically use the updated information whenever [new nodes are added](../../pages-for-subheaders/use-new-nodes-in-an-infra-provider.md).
|
||||
|
||||
## Deleting a Cloud Credential
|
||||
|
||||
In order to delete cloud credentials, there must not be any node template associated with it. If you are unable to delete the cloud credential, [delete any node templates](manage-node-templates.md#deleting-a-node-template) that are still associated to that cloud credential.
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Click **Cloud Credentials**.
|
||||
1. You can either individually delete a cloud credential or bulk delete.
|
||||
|
||||
- To individually delete one, choose the cloud credential you want to edit and click the **⋮ > Delete**.
|
||||
- To bulk delete cloud credentials, select one or more cloud credentials from the list. Click **Delete**.
|
||||
1. Confirm that you want to delete these cloud credentials.
|
||||
@@ -0,0 +1,54 @@
|
||||
---
|
||||
title: Managing Node Templates
|
||||
---
|
||||
|
||||
When you provision a cluster [hosted by an infrastructure provider](../../pages-for-subheaders/use-new-nodes-in-an-infra-provider.md), [node templates](../../pages-for-subheaders/use-new-nodes-in-an-infra-provider.md#node-templates) are used to provision the cluster nodes. These templates use Docker Machine configuration options to define an operating system image and settings/parameters for the node. You can create node templates in two contexts:
|
||||
|
||||
- While [provisioning a node pool cluster](../../pages-for-subheaders/use-new-nodes-in-an-infra-provider.md).
|
||||
- At any time, from your [user settings](../../pages-for-subheaders/user-settings.md).
|
||||
|
||||
When you create a node template, it is bound to your user profile. Node templates cannot be shared among users. You can delete stale node templates that you no longer user from your user settings.
|
||||
|
||||
## Creating a Node Template
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Click **RKE1 Configuration > Node Templates**.
|
||||
1. Click **Add Template**.
|
||||
1. Select one of the cloud providers available. Then follow the instructions on screen to configure the template.
|
||||
|
||||
**Result:** The template is configured. You can use the template later when you [provision a node pool cluster](../../pages-for-subheaders/use-new-nodes-in-an-infra-provider.md).
|
||||
|
||||
## Updating a Node Template
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Click **RKE1 Configuration > Node Templates**.
|
||||
1. Choose the node template that you want to edit and click the **⋮ > Edit**.
|
||||
|
||||
:::note
|
||||
|
||||
The default `active` [node drivers](../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/about-provisioning-drivers/manage-node-drivers.md) and any node driver, that has fields marked as `password`, are required to use [cloud credentials](../../pages-for-subheaders/use-new-nodes-in-an-infra-provider.md#cloud-credentials).
|
||||
|
||||
:::
|
||||
|
||||
1. Edit the required information and click **Save**.
|
||||
|
||||
**Result:** The node template is updated. All node pools using this node template will automatically use the updated information when new nodes are added.
|
||||
|
||||
## Cloning Node Templates
|
||||
|
||||
When creating new node templates from your user settings, you can clone an existing template and quickly update its settings rather than creating a new one from scratch. Cloning templates saves you the hassle of re-entering access keys for the cloud provider.
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Click **RKE1 Configuration > Node Templates**.
|
||||
1. Find the template you want to clone. Then select **⋮ > Clone**.
|
||||
1. Complete the rest of the form.
|
||||
|
||||
**Result:** The template is cloned and configured. You can use the template later when you [provision a node pool cluster](../../pages-for-subheaders/use-new-nodes-in-an-infra-provider.md).
|
||||
|
||||
## Deleting a Node Template
|
||||
|
||||
When you no longer use a node template, you can delete it from your user settings.
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Click **RKE1 Configuration > Node Templates**.
|
||||
1. Select one or more template from the list. Then click **Delete**. Confirm the delete when prompted.
|
||||
@@ -0,0 +1,62 @@
|
||||
---
|
||||
title: User Preferences
|
||||
---
|
||||
|
||||
You can set preferences to personalize your Rancher experience. To change preference settings:
|
||||
|
||||
1. Click on your user avatar in the upper right corner.
|
||||
1. Click **Preferences**.
|
||||
|
||||
## Language
|
||||
|
||||
Choose your language for the Rancher UI. Options include:
|
||||
|
||||
- English
|
||||
- 简体中文 (Simplified Chinese)
|
||||
|
||||
## Theme
|
||||
|
||||
Choose your background color for the Rancher UI. If you choose **Auto**, the background color changes from light to dark at 6 PM, and then changes back at 6 AM.
|
||||
|
||||
## Login Landing Page
|
||||
|
||||
Choose the page displayed after logging in. Options include:
|
||||
|
||||
- The home page.
|
||||
- The area you last visited.
|
||||
- A specific cluster of your choosing.
|
||||
|
||||
## Display Settings
|
||||
|
||||
Choose how certain information is displayed:
|
||||
|
||||
- Date format
|
||||
- Time format
|
||||
- Table rows per page
|
||||
- Number of clusters to show in side menu
|
||||
|
||||
## Confirmation Setting
|
||||
|
||||
_Available as of v2.7.2_
|
||||
|
||||
Choose whether to ask for confirmation when scaling down node pools.
|
||||
|
||||
## Advanced Features
|
||||
|
||||
- Enable "View in API".
|
||||
- Show system Namespaces managed by Rancher (not intended for editing or deletion).
|
||||
- Enable Dark/Light Theme keyboard shortcut toggle (shift+T).
|
||||
- Hide All Type Descriptions.
|
||||
- Enable Extension developer features.
|
||||
|
||||
|
||||
|
||||
## YAML Editor Key Mapping
|
||||
|
||||
- Normal human (Sublime)
|
||||
- Emacs
|
||||
- Vim
|
||||
|
||||
## Helm Charts
|
||||
|
||||
Choose whether to display released Helm charts only or to include prerelease versions as well. A version is considered to be a prerelease if it adheres to [the specification](https://semver.org/#spec-item-9) defined by [Semantic Versioning 2.0.0](https://semver.org/). For example, a Helm chart with a version of `0.1.3-dev.12ab4f` requires `Include Prerelease Versions` to be selected in order to be displayed.
|
||||
Reference in New Issue
Block a user