rancher / rancher-docs Goto Github PK

Rancher Documentation

Home Page: https://ranchermanager.docs.rancher.com/

License: Apache License 2.0

JavaScript 94.34% CSS 3.72% MDX 0.55% TypeScript 1.39%

rancher-docs's Introduction

Contribute to Rancher Docs

Welcome to the Rancher docs repository. See the Rancher software repository if you have questions or requests for the Rancher platform.

Make a Suggestion

You can suggest changes to the Rancher docs in two ways:

Open an issue.
Edit the docs in the way you see fit and open a pull request.

Edit the Docs

To get started, fork and clone the rancher-docs repository.

Our repository doesn't allow you to make changes directly to the main branch. Create a working branch and make pull requests from your fork to rancher/rancher-docs.

For most updates, you'll need to edit a file in the /docs directory, which represents the "Latest" version of our published documentation. The "Latest" version is a mirror of the most recently released version of Rancher. As of August 2024, the most recently released version of Rancher is 2.9.

Whenever an update is made to /docs, you should apply the same change to the corresponding file in /versioned_docs/version-2.9. If a change only affects older versions, you don't need to mirror it to the /docs directory.

If a file is moved or renamed, you'll also need to edit the sidebars.js files for each affected version, as well as the list of redirects in docusaurus.config.js. See Moving or Renaming Docs.

Navigate the Repo

The file paths in the repo correspond to the URLs for pages on the docs website. The docs for the latest version of Rancher are located in /docs. All images are in /static/img in the top level of the repo. Older docs are found within /versioned_docs and generally follow the same structure as the files in /docs.

Style & Formatting

The docs are written in Markdown. We use standard American English and many pages are also available in Simplified Chinese.

Moving forward, we are referring to the SUSE style guide. The Style check / runner / vale (pull_request) check used Vale to make style and grammar suggestions for new or updated documentation based on the SUSE style guide. To review these suggestions when working on a PR:

Select the details of the Style check / runner / vale (pull_request) check.
In the logs, go to Run errata-ai/[email protected] and select Running vale with reviewdog 🐶 ... to view the suggestions.
New or updated files are checked against the SUSE style guide. Suggestions have the following format: '{"message": "[suse-vale-styleguide.Rule] Rule description", "location": {"path": "file-path", "range": {"start": {"line": , "column": }}}, "severity": " "}'

For example: '{"message": "[suse-vale-styleguide.Usage] Use 'certain' instead of 'some'", "location": {"path": "docs/contribute-to-rancher.md", "range": {"start": {"line": 3, "column": 132}}}, "severity": "WARNING"}'
Incorporate the suggestions when possible and appropriate.

Every docs page contain metadata in the first few lines:

---
title: Some Title
---

The title is rendered as the page's headline. The site renderer wraps the title value in H1 tags, which are equivalent to # in Markdown syntax. This means that all subsequent headers on the page should be second level (##) or more.

Run the Docs Website

The Rancher Docs website is built with Docusaurus 2, a modern static website generator.

You can run the site on your local machine, to preview how pages on your working branch will look live.

First, install Docusaurus 2:

If you haven't already, install Node and Yarn.
Go into your local rancher-docs folder.
The Rancher Docs repository already contains a yarn.lock file, which contains the dependencies you need to build the website. Run yarn to install Docusaurus and associated dependencies.

Start Site

yarn start

This command starts a local development server for Docusaurus 2, and opens up a browser window. Most changes are reflected live without having to restart the server.

Note: The yarn start command won't include some important static site features. For example, switching between languages from the site's dropdown menu is not available. If you need these features, use yarn build.

Build Site

yarn build

This command generates static content into the build directory and can be served using any static contents hosting service.

Launch With Docker

You can also use Docker to launch the website.

The below command can be used to install the dependencies and run the site inside a container:

docker run --rm -it -v $PWD:$PWD -w $PWD -p 3000:3000 node:18 /bin/sh -c "yarn install && yarn start -h 0.0.0.0"

Subsequent executions will check for updated dependencies, if there are none, it will skip the updates and quickly start the server.

License

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

rancher-docs's People

Contributors

Stargazers

Watchers

Forkers

btat jtravee vickyhella a-blender catherineluse frank-at-suse maximiliankindshofer musaprg kokoye2007 doflamingo721 reylejano maxsokolovsky tejeev nunix bashofmann mitulshah-suse ppsteven mbolotsuse dkeightley 290760647 mehran-prs kevinjoiner pierrevillard hkchan0709 pascallps moio stormqueen1990 soonyigkka a1198457636 suyambuganesh82 suryatejaboorlu sodisys rmweir asloan7 chinmaya-n dagobertoluiz kourosh7 ax88008 sandipnikale imcaoxuan vrevelas cycwll peacock-2000 iamcloudmonkey celidon martyav stefanlasiewski brianalmeida krishnamohan-yerrabilli eric-domeier guopeizhao shiveshabhishek jpartain89 sunilarjun lucassaintarbor jiaqiluo kevinayres krmartin cbron crobby suse-gabrielblais noblem rancher-sandbox rtchegnon fekete-robert loubnaiguermazda sakuraaxy dgiebert josh-diamond jainpulkit22 rajnkamr kshtsk heyitang kkaempf vivek-shilimkar jonesa-caci ashawka jschaef joncrowther maiguangchao boramyleng ssagarshiva juanbrny e-minguez sumitnits clemenko tlatino aaron0tw dprodanov4 pjbgf christoph-puppe nflynt 90er pavlodem roycec ajaychinthapalli fbrokanlou yooahin eliyamlevy richardcase

rancher-docs's Issues

Document how to import a cluster with the Rancher API

This issue represents a small piece of the work in #173

Example IAM Policy for Rancher EBS

Origin issue rancher/rancher#9343

I am unable to find documentation anywhere that states the level of permissions a user or role should have for the EBS driver to work. Can this please be added to the documentation.

I was going to write a blog post on this, and I might still, but here is a working policy. There might be some room to restrict the permissions a little further, but it's pretty specific and locked down now.

This policy assumes that you are adding tags to your resources, ec2 and ebs

Rancher = managed
Environment = <some env name>

This policy allows the rancher-ebs to create ebs volumes and then tag them at creation, because of those tags it allows rancher-ebs to attach and detach only the ebs volumes it creates and only against the aws instances that are controlled by rancher (specified by tags)

Note: I use terraform, therefore the variables below, but this should be a good starting point @superseb if you are interested.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
              "ec2:DescribeInstances"
            ],
            "Resource": [
                "arn:aws:ec2:${var.region}:${var.account_id}:instance/*"
            ],
            "Condition": {
              "StringEquals": {
                "ec2:ResourceTag/Rancher": "managed",
                "ec2:ResourceTag/Environment": "${var.environment}"
              }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
              "ec2:AttachVolume",
              "ec2:DetachVolume"
            ],
            "Resource": [
                "arn:aws:ec2:${var.region}:${var.account_id}:instance/*",
                "arn:aws:ec2:${var.region}:${var.account_id}:volume/*"
            ],
            "Condition": {
              "StringEquals": {
                "ec2:ResourceTag/Rancher": "managed",
                "ec2:ResourceTag/Environment": "${var.environment}"
              }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "ec2:CreateVolume",
                "ec2:CreateSnapshot",
                "ec2:CreateTags",
                "ec2:DescribeAvailabilityZones",
                "ec2:DescribeVolumeAttribute",
                "ec2:DescribeVolumesModifications",
                "ec2:DescribeVolumeStatus",
                "ec2:DescribeVolumes",
                "ec2:DescribeSnapshots",
                "ec2:DescribeTags"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "ec2:DeleteVolume",
                "ec2:ModifyVolume",
                "ec2:ModifyVolumeAttribute"
            ],
            "Resource": [
                "arn:aws:ec2:${var.region}:${var.account_id}:volume/*"
            ],
            "Condition": {
              "StringEquals": {
                "ec2:ResourceTag/Rancher": "managed",
                "ec2:ResourceTag/Environment": "${var.environment}"
              }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
              "kms:DescribeKey",
              "kms:Encrypt",
              "kms:Decrypt",
              "kms:GenerateDataKey",
              "kms:GenerateDataKeyWithoutPlaintext",
              "kms:CreateGrant",
              "kms:ListGrants",
              "kms:RevokeGrant"
            ],
            "Resource": [
              "${var.kms_key_arn}"
            ]
        }
    ]
}

Rancher EBS can do that if you pass in the right values ... here's an example

volumes:
  db-data:
    driver: rancher-ebs
    driver_opts:
      size: ${rancher_ebs_volume_size}
      volumeType: "gp2"
      ec2_az: ${rancher_ebs_ec2_az}
      encrypted: true
      kmsKeyId: ${rancher_ebs_kms_key_id}
      tags: "Key=Rancher,Value=managed Key=Environment,Value=${environment}"

Docs for feature: Private Registry (Harbor)

API in version 2

We are trying to create a project, assign members & owners, create a deployment with persistent storage all through the API. The lack of documentation is a severe limitation on our efforts.

Document how to change settings with the Rancher API

This issue represents a small piece of the work in #173

Clean up existing API docs and expand 'getting started' topics

This issue represents the "Getting Started" section of this issue about expanding the API docs: #173

(I'm making smaller issues related to the API docs to make them easier to track)

Update Okta Configuration Guide with HA methodology

During configuration of the Okta authentication provider in an HA Environment the Validation and Enablement step kept failing with a 502 Bad Gateway

After investigation it was discovered:

Okta won't be enabled on Rancher until it can be validated

This meant that as we were HA whenever we begun the validation request the returned validation saml token would be routed by the external LB to a different rancher server than the requester (causing the bad gateway)

Rancher could never complete the validation for at least one node and never became enabled on any of them as a result and would continuously fail

To resolve this we cordoned off two of the nodes in the GUI to force traffic to the requester and from there completed the validation, this then synced the Okta configuration to the two other nodes

We tested each node cordoned individually to ensure the Okta configuration had been synced and also when all three were uncordoned with no difficulties

This has not yet being validated with any other providers except Okta yet but may require it

However looking in the guide I can't see this described anywhere

Could we please update the docs to reflect this necessary step for HA Envs with Okta if possible?

Enumerate in detail the Azure AD Requirements

There's been some questions in the community about why we need the various permissions we need for Azure AD. We should spell out the whys in detail.

rancher/rancher#22449

Add Documentation on how to manually configure the prometheus adapter

Document how to initally set up server with Rancher API

This issue represents a small piece of the work in #173

Document kubernetes thresholds

Provide guidelines around the number of resources (pods, deployments, etc) at the Namespace and Cluster level.

We need to run tests against the documented Kubernetes limits, and provide tuning information for Rancher and the K8s settings.

gz#3554

Clean up existing API docs and expand 'getting started' topics

This issue represents the "Getting Started" section of this issue about expanding the API docs: #173

(I'm making smaller issues related to the API docs to make them easier to track)

Azure cloud-provider requires extra permissions to use AzureFiles

The origin issue is rancher/rancher#13947

Not sure this is truly an issue with Rancher, seems like the cloud-provider should do this for you, but I know our users are going to trip over this.

To dynamically configure AzureFiles volumes, the provider/controller needs permissions to create a secret to store the share credentials in the namespace the pvc was created in.

kubectl create clusterrole system:azure-cloud-provider --verb=get,create --resource=secrets
kubectl create clusterrolebinding system:azure-cloud-provider --clusterrole=system:azure-cloud-provider --serviceaccount=kube-system:persistent-volume-binder

Related issues:
kubernetes/kubernetes#59543

Related documentation:
The storageClass docs sort of mention that this is required as a side note.
https://kubernetes.io/docs/concepts/storage/storage-classes/#azure-file

Rancher versions:
rancher/rancher: v2.0.2

Clean up existing API docs and expand 'getting started' topics

This issue represents the "Getting Started" section of this issue about expanding the API docs: #173

(I'm making smaller issues related to the API docs to make them easier to track)

Document how to upgrade a workload with the Rancher API

This issue represents a small piece of the work in #173

Clean up existing API docs and expand 'getting started' topics

This issue represents the "Getting Started" section of this issue about expanding the API docs: #173

(I'm making smaller issues related to the API docs to make them easier to track)

Add new chart options to the chart options page in the installation section

We have added a few new chart options, for example, the option to enable experimental features. But not all the new options have been added to this complete list, so we should update it.

Please provider better/more restrictive AWS IAM policies

Origin issue is rancher/rancher#15744
Rancher versions:
rancher/server or rancher/rancher: 2.0.8

The example IAM policies for an AWS EC2 cluster are way too permissive. For anyone seriously running R2 in AWS, these policies shouldn't be used nor should they even be promoted outside of a development setting. The essentially give free reign on all ec2 resources.

It would be nice to get a subject matter expert from Rancher who understands what permissions are actually needed to help form IAM policies that are more specific.

An example of a more restrictive policy is the one I wrote for EBS volumes on R1 EBS Volume Plugin, it limits the capabilities of the node to generate volumes and then only delete the ones it created, as well as attach and detach nodes that are under rancher's control rancher/rancher#9343 (comment)

So far my attempts to use R2 K8S AWS Cloud Provider and provide a more restrictive IAM policy has resulted in many things not working. I finally got node creation to work, but I am unable to get EBS volumes to work.

Provide more detail about how Rancher's role promotion logic is

https://rancher.com/docs/rancher/v2.x/en/admin-settings/rbac/default-custom-roles/

@catherineluse you will need to speak to @cjellick to get details

Document rancher metrics endpoint

Rancher has a metrics endpoint that can provide information to a Prometheus instance which allows for fine-grain information about Rancher. This information allows for more observability into Rancher.
See rancher/rancher#20341

We should document how to set this up and a brief description of all the fields exposed.

Prometheus config:

scrape_configs:
     - job_name: rancher
      scheme: https
      bearer_token: {{ rancher_metrics_token.stdout }}
      scrape_interval: 15s
      kubernetes_sd_configs:
      - role: pod
      relabel_configs:
      - action: keep
        regex: cattle-system;cattle;cattle-server;443
        source_labels:
        - __meta_kubernetes_namespace
        - __meta_kubernetes_pod_label_app
        - __meta_kubernetes_pod_label_component
        - __meta_kubernetes_pod_container_port_number
      tls_config:
        ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
        insecure_skip_verify: true

gz#11710

Rancher V3 API Documentation

origin issue is rancher/rancher#14190

Review comments in code block for S3 snapshots in RKE 0.2.0+

The documented code block [1] has comments indicating retention is:

      retention: 60     # time in days before snapshot purge

Whereas, in RKE v0.2.0+ retention is "Number of snapshots to retain" [2].

[1] https://rancher.com/docs/rancher/v2.x/en/backups/backups/ha-backups/#option-a-recurring-snapshots
[2] https://rancher.com/docs/rancher/v2.x/en/cluster-admin/backing-up-etcd/#configuring-recurring-snapshots-for-the-cluster

Explain undocumented options in Rancher CLI docs

This doc issue comes from this Slack conversation:

the rancher cli has undocumented options for example rancher up is available in the v2.2.0 cli. But that option is not documented here https://rancher.com/docs/rancher/v2.x/en/cli/

adrian [12:04 PM]
i think it's legacy 1.6. it's analagous to docker-compose up
or at least it was

dan [12:08 PM]
It's for importing a cluster and projects

cjellick [12:49 PM]
@dan link that doc where it actually does explain this. It’s actually well documented just not where the rest of cli docs are I think

dan [1:11 PM]
@mak3r we refer to it as 'cloning a cluster' in the docs https://rancher.com/docs/rancher/v2.x/en/cluster-admin/cloning-clusters/ (edited)
But I agree, the cli help needs updated

Clean up existing API docs and expand 'getting started' topics

This issue represents the "Getting Started" section of this issue about expanding the API docs: #173

(I'm making smaller issues related to the API docs to make them easier to track)

Document all the types in rancher/types, grouped by scope, for Rancher API users

This issue represents a small piece of the work in #173

This should include human-readable descriptions of what each type is used for.

There should be a table of the fields with the type, description, and restrictions.

NFS storage example seems to refer to documentation that does not exist

Ref:
https://rancher.com/docs/rancher/v2.x/en/cluster-admin/volumes-and-storage/examples/nfs/
https://rancher.com/docs/rancher/v2.x/en/cluster-admin/volumes-and-storage/
https://forums.rancher.com/t/nfs-provisioner-for-storageclass/13109

The first link implies you can find instructions for utilizing an already deployed NFS server at the second link but the second repeatedly mentions that you must have the cloud provider enabled for the cluster and use the related storage provider. It appears you can create a storage provider that is not outlined by the cloud provider or dependent on it, but that it is not currently within Rancher's sphere of support.

It would be good to have a section about creating storage classes that are not dependent on the cloud provider and one on how one might 'use the NFS volume plugin within Rancher', as the first doc says you can do.

It might be a different issue, but the whole volumes-and-storage document is somewhat repetitive and unclear. Some sections are written from the perspective of an RKE cluster but there's no clarification on the differences or the particulars of a non RKE cluster.

Document how to deploy a workload with the Rancher API

This issue represents a small piece of the work in #173

API Docs

Edited by Catherine in February 2020:

After a discussion with Vince, we're going to do this in a slightly different order.

Part 1 - Basics

Use the API in the browser
Get API Keys
Make requests - say actions are POSTs
Levels of scope - describe scopes of API
Show where types and schemas are

Part 2 - Document operations that have a global scope

Focus on showing how to use the Rancher API for manipulating things outside the scope of a cluster, because the kubectl CLI can be used to manipulate resources within clusters.

We will show how to:

Initially set up a Rancher server
Change settings
Create a custom cluster (custom clusters use an RKE config type, and other configs are used for other clusters)
Create an imported cluster
RBAC
Authentication, adding users and groups
Node templates
Cloud credentials

Long term goals for API docs

The Rancher API view should eventually be documented with a similar format and similar process used in the Kubernetes API reference: https://kubernetes.cn/docs/reference/generated/kubernetes-api/v1.13/
Automated API doc generation, starting with types, which are currently listed under ‘schemas’ in the Rancher API at [Rancher server URL]/v3/schemas
Create JSON or YAML schema generated from the Rancher API view in order to make Swagger docs
Add more human-readable descriptions to types and other API resources
Pipelines and custom catalogs with the Rancher API

Edit October 20 2020:

The requirements for a fully documented API reference will be:

Must document all types
Must list all of the fields, options, actions, sortings, etc
Must describe the fields, what type they are, what kind of values are allowed, or which ones are required
Any examples must be tested
The API reference must be organized by the scope of the resources, with global scoped, cluster scoped, and project scoped resources

Document how to handle websockets/watches/change events with the Rancher API

This issue represents a small piece of the work in #173

Alerting documentation difficult to follow

Customer requests more examples of how to build alerting expressions as well as how to build expressions for more than one condition. It would also be helpful to reference the promQL syntax, something like: https://prometheus.io/docs/prometheus/latest/querying/operators/

rancher-images.txt

The Rancher project curates a list of images (rancher-images.txt) needed to run Rancher, especially for the air gap installation method.

The German Federal Office for Information Security has published a guide for container security. Based on this, the following questions come up:

Do you check every image on the rancher-images.txt list for known vulnerabilities?
Do you check that the images on the rancher-images.txt are from a trusted source?
As soon as a vulnerability in the images becomes known, will you release a new version or inform about a new version?
Do you have specific policies for creating images?
Do you use certain policies when checking whether images are added to the rancher-images.txt list?

Can you document which policies are used when images are included in this list?

Clean up existing API docs and expand 'getting started' topics

This issue represents the "Getting Started" section of this issue about expanding the API docs: #173

(I'm making smaller issues related to the API docs to make them easier to track)

Consider adding additional configuration options for DNS providers

Opening this to consider adding information or link for additional DNS provider configuration.

For example, to persist custom CoreDNS ConfigMaps throughout cluster upgrades (by default resets the ConfigMap) it is possible to do this in-line

Example:

rancher_kubernetes_engine_config:
[...]
  addons: |-
      ---
      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: coredns
        namespace: kube-system
      data:
        Corefile: |
          .:53 {
              errors
              log
              health {
                lameduck 5s
              }
              ready
              kubernetes cluster.local in-addr.arpa ip6.arpa {
                pods insecure
                fallthrough in-addr.arpa ip6.arpa
              }
              prometheus :9153
              forward . "/etc/resolv.conf"
              cache 30
              loop
              reload
              loadbalance
          }

Document how to call the k8s API with the Rancher API

This issue represents a small piece of the work in #173

Provide more detail about how Rancher's role promotion logic is

https://rancher.com/docs/rancher/v2.x/en/admin-settings/rbac/default-custom-roles/

@catherineluse you will need to speak to @cjellick to get details

Update project roles documentation to reflect self-service behavior

Update documentation to clarify the unique behavior of namespace resources for project roles.

With the self-service workflow, project roles will automatically inherit read/update/delete permissions for namespaces in the project

In addition, a project role that gives permission to cluster-scoped resources (PersistentVolumes, StorageClasses, and ApiServices) will be applied at the cluster level.

https://rancher.com/docs/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles

Clean up existing API docs and expand 'getting started' topics

This issue represents the "Getting Started" section of this issue about expanding the API docs: #173

(I'm making smaller issues related to the API docs to make them easier to track)

NFS storage example seems to refer to documentation that does not exist

Custom Resource Defintion API in Rancher 2.0

From what I can tell, there is no good API definition/guide available on our Docs at the moment for custom resource definitions.

Describe how to export node templates with the Rancher API

Document how to scale a workload with the Rancher API

This issue represents a small piece of the work in #173

AWS Policy template to setup an EC2 cluster fails to be created

Hi,

I am trying to configure a new cluster with Rancher on AWS, by clicking "Add Node Template" I got "
UnauthorizedOperation: You are not authorized to perform this operation."

I reviewed the documentation per-requisites and tried to create the IAM policy according to the examples at:

https://rancher.com/docs/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/ec2/#example-iam-policy-with-passrole

AWS' IAM policy fails to be created with:

"An error occurred
Your request has a problem. Please see the following details.
The policy failed legacy parsing "

Thanks in advance for any feedback.

Cheers.

Jose

single-node install backup instructions contradict each other

In the instructions for creating a backup on Single Node (https://rancher.com/docs/rancher/v2.x/en/backups/backups/single-node-backups/)

when getting into the steps of what to do, the first step says to stop the actual running container of Rancher. The second step then says to do a docker create command that relies on the RANCHER_CONTAINER_NAME of the image that was just stopped. If the image is stopped it no longer is available for the docker create command to run. Will result in error stating "No such image"

a docker ps command will show that the image that was previously running is no longer running, thus cannot be used in future commands.

Document how to execute a command in a pod with the Rancher API

This issue represents a small piece of the work in #173

Document IPA RBAC permissions requirment for the FreeIPA service account

rancher/rancher#20336 (comment)

Document steps to set a proxy for imported cluster agents

Currently there are no documented steps on how to specify a proxy for the cluster/node agents in an imported cluster.

Steps are:

Add Cluster > Import an existing cluster > Create
Download the yaml specified in the command
Edit the yaml to add the proxy environment variables to both the cluster agent deployment and node agent daemonset:

env:
- name: CATTLE_SERVER
  value: "https://rancher.url"
- name: CATTLE_CA_CHECKSUM
  value: "8885a3b0ad0a89a8cf98b069614589cd8729be28c967c660ad3bba30e97e7af7"
- name: CATTLE_CLUSTER
  value: "true"
- name: CATTLE_K8S_MANAGED
  value: "true"
- name: HTTP_PROXY
  value: "proxy.url:3128"
- name: HTTPS_PROXY
  value: "proxy.url:3128"
- name: NO_PROXY
  value: "localhost,127.0.0.1,0.0.0.0"

Run kubectl apply with the locally modified file: kubectl apply -f cluster-import.yaml
The cluster will register and the agents will be using the specified proxy.

Add documentation for logging security events

Copied from rancher/rancher#17432

Customers need to be able to log various security events that take place with Rancher for auditing purposes. We need to better document how this is done.

What kind of request is this (question/bug/enhancement/feature request):
Enhancement

Certificate Chain - Adding/creating a validator as well as documenting about them

Certificate Chains aren't well understood by customers.

Rancher agent uses the full chain to connect to rancher server.

Add learning content. Review existing stuff about cert chains. Describe that you have to pass down the construction of the entire chain.

NFS storage example seems to refer to documentation that does not exist

Document how to create a custom cluster with the Rancher API

This issue represents a small piece of the work in #173

rancher / rancher-docs Goto Github PK

rancher-docs's Introduction

Contribute to Rancher Docs

Make a Suggestion

Edit the Docs

Navigate the Repo

Style & Formatting

Run the Docs Website

Start Site

Build Site

Launch With Docker

License

rancher-docs's People

Contributors

Stargazers

Watchers

Forkers

rancher-docs's Issues

Part 1 - Basics

Part 2 - Document operations that have a global scope

Long term goals for API docs

Recommend Projects

Recommend Topics

Recommend Org