diff --git a/build.assets/tooling/cmd/render-helm-ref/main.go b/build.assets/tooling/cmd/render-helm-ref/main.go index cfa0bd7a27b..0b4af23e9db 100644 --- a/build.assets/tooling/cmd/render-helm-ref/main.go +++ b/build.assets/tooling/cmd/render-helm-ref/main.go @@ -143,12 +143,13 @@ type Value struct { Name string Kind string - Description strings.Builder + Description string Default string } type state struct { isDescription bool + description strings.Builder value *Value } @@ -177,8 +178,8 @@ func grabValue(comment string) *Value { // start of a value documentation s.isDescription = true s.value = &Value{Name: name, Kind: kind} - s.value.Description.WriteString(remain) - s.value.Description.WriteRune('\n') + s.description.WriteString(remain) + s.description.WriteRune('\n') continue } // We already saw a tag on a previous line @@ -188,8 +189,12 @@ func grabValue(comment string) *Value { s.value.Default = defaultValue continue } - s.value.Description.WriteString(cleanLine(line)) - s.value.Description.WriteRune('\n') + s.description.WriteString(cleanLine(line)) + s.description.WriteRune('\n') + } + + if s.isDescription { + s.value.Description = strings.TrimSpace(s.description.String()) } return s.value } diff --git a/build.assets/tooling/cmd/render-helm-ref/template.go b/build.assets/tooling/cmd/render-helm-ref/template.go index 009a440a4fc..e333ed7e457 100644 --- a/build.assets/tooling/cmd/render-helm-ref/template.go +++ b/build.assets/tooling/cmd/render-helm-ref/template.go @@ -37,8 +37,11 @@ const referenceTemplate = ` | ` + "`" + `{{.Kind}}` + "`" + ` | ` + "`" + `{{.Default}}` + "`" + ` | {{- end }} +{{- if .Description }} + ` + "`" + `{{.Name}}` + "`" + ` {{ .Description }} -{{- end -}}` +{{- end }} +{{ end -}}` func renderTemplate(values []*Value) ([]byte, error) { t := template.Must(template.New("reference").Funcs(sprig.FuncMap()).Parse(referenceTemplate)) diff --git a/build.assets/tooling/cmd/render-helm-ref/testdata/expected-output.mdx b/build.assets/tooling/cmd/render-helm-ref/testdata/expected-output.mdx index 102c5bc64cf..7461c367704 100644 --- a/build.assets/tooling/cmd/render-helm-ref/testdata/expected-output.mdx +++ b/build.assets/tooling/cmd/render-helm-ref/testdata/expected-output.mdx @@ -35,6 +35,16 @@ created by the chart. `annotations.pod` controls the Kubernetes Pod annotations... +## `labels` + +### `labels.deployment` + +| Type | Default | +|------|---------| +| `object` | `{}` | + +`labels.deployment` controls ... + ## `podSecurityContext` | Type | Default | diff --git a/build.assets/tooling/cmd/render-helm-ref/testdata/values.yaml b/build.assets/tooling/cmd/render-helm-ref/testdata/values.yaml index 15ad5367a80..d8eb1e9ab9a 100644 --- a/build.assets/tooling/cmd/render-helm-ref/testdata/values.yaml +++ b/build.assets/tooling/cmd/render-helm-ref/testdata/values.yaml @@ -22,6 +22,12 @@ annotations: # annotations.pod(object) -- controls the Kubernetes Pod annotations... pod: {} +# Just add the title, no description nor table. +# labels -- +labels: + #labels.deployment(object) -- controls ... + deployment: {} + # Nested values documented at the parent level. # The podSecurityContext is documented as a single value. Its default will # be serialized in JSON. diff --git a/docs/config.json b/docs/config.json index 1f6ea3ea386..d8129749c35 100644 --- a/docs/config.json +++ b/docs/config.json @@ -534,17 +534,25 @@ "slug": "/management/dynamic-resources/", "entries": [ { - "title": "Kubernetes Operator", - "slug": "/management/dynamic-resources/teleport-operator/", - "forScopes": ["oss","enterprise"] - }, - { - "title": "Terraform Provider", - "slug": "/management/dynamic-resources/terraform-provider/" - }, + "title": "Kubernetes Operator", + "slug": "/management/dynamic-resources/teleport-operator/" + }, + { + "title": "Kubernetes Operator in teleport-cluster Helm chart", + "slug": "/management/dynamic-resources/teleport-operator-helm/", + "forScopes": ["oss","enterprise"] + }, + { + "title": "Standalone Kubernetes Operator", + "slug": "/management/dynamic-resources/teleport-operator-standalone/" + }, + { + "title": "Terraform Provider", + "slug": "/management/dynamic-resources/terraform-provider/" + }, { - "title": "Spacelift", - "slug": "/management/dynamic-resources/spacelift/" + "title": "Spacelift", + "slug": "/management/dynamic-resources/spacelift/" } ] }, @@ -1617,6 +1625,10 @@ "title": "teleport-kube-agent", "slug": "/reference/helm-reference/teleport-kube-agent/" }, + { + "title": "teleport-operator", + "slug": "/reference/helm-reference/teleport-operator/" + }, { "title": "teleport-plugin-event-handler", "slug": "/reference/helm-reference/teleport-plugin-event-handler/" diff --git a/docs/pages/access-controls/login-rules/kubernetes.mdx b/docs/pages/access-controls/login-rules/kubernetes.mdx index eee64e7a4ce..a74eb65b252 100644 --- a/docs/pages/access-controls/login-rules/kubernetes.mdx +++ b/docs/pages/access-controls/login-rules/kubernetes.mdx @@ -39,10 +39,10 @@ This guide is applicable if you self-host Teleport in Kubernetes using the -- Follow Step 1 of the - [Teleport operator guide](../../management/dynamic-resources/teleport-operator.mdx#step-13-install-teleport-cluster-helm-chart-with-the-operator) +- Follow the [Teleport operator guides](../../management/dynamic-resources/teleport-operator.mdx) to install the Teleport Operator in your Kubernetes cluster. - Make sure to follow the Enterprise instructions. + Make sure to follow the Enterprise instructions if you're deploying the + operator as part of the `teleport-cluster` chart. Confirm that the CRD (Custom Resource Definition) for Login Rules has been installed with the following command: diff --git a/docs/pages/includes/diagnostics/kubernetes-operator-troubleshooting.mdx b/docs/pages/includes/diagnostics/kubernetes-operator-troubleshooting.mdx new file mode 100644 index 00000000000..a02bc90c399 --- /dev/null +++ b/docs/pages/includes/diagnostics/kubernetes-operator-troubleshooting.mdx @@ -0,0 +1,60 @@ +The Teleport Operator watches for new resources or changes in Kubernetes. +When a change happens, it triggers the reconciliation loop. This loop is in +charge of validating the resource, checking if it already exists in Teleport +and making calls to the Teleport API to create/update/delete the resource. +The reconciliation loop also adds a `status` field on the Kubernetes resource. + +If an error happens and the reconciliation loop is not successful, an item in +`status.conditions` will describe what went wrong. This allows users to diagnose +errors by inspecting Kubernetes resources with `kubectl`: + +```code +$ kubectl describe teleportusers myuser +``` + +For example, if a user has been granted a nonexistent role the status will look like: + +```yaml +apiVersion: resources.teleport.dev/v2 +kind: TeleportUser +# [...] +status: + conditions: + - lastTransitionTime: "2022-07-25T16:15:52Z" + message: Teleport resource has the Kubernetes origin label. + reason: OriginLabelMatching + status: "True" + type: TeleportResourceOwned + - lastTransitionTime: "2022-07-25T17:08:58Z" + message: 'Teleport returned the error: role my-non-existing-role is not found' + reason: TeleportError + status: "False" + type: SuccessfullyReconciled +``` + +Here `SuccessfullyReconciled` is `False` and the error is `role my-non-existing-role is not found`. + +If the status is not present or does not give sufficient information to solve +the issue, check the operator logs: + +```shell +$ kubectl logs deploy/ +``` + + + In case of multi-replica deployments, only one operator instance is running + the reconciliation loop. This operator is called the leader and is the only + one producing reconciliation logs. The other operator instances are waiting + with the following log: + + ``` + leaderelection.go:248] attempting to acquire leader lease teleport/431e83f4.teleport.dev... + ``` + + To diagnose reconciliation issues, you will have to inspect all pods to find + the one reconciling the resources. + + +If the Kubernetes resource has no status update and the operator does not produce +any logs regarding the resource, please check if the resource lives in the same +namespace as the operator. The operator only watches for resource in its own namespace. diff --git a/docs/pages/management/dynamic-resources/teleport-operator-helm.mdx b/docs/pages/management/dynamic-resources/teleport-operator-helm.mdx new file mode 100644 index 00000000000..eb393b89684 --- /dev/null +++ b/docs/pages/management/dynamic-resources/teleport-operator-helm.mdx @@ -0,0 +1,180 @@ +--- +title: Kubernetes Operator in teleport-cluster Helm chart +description: Deploy the operator alongside your Helm-deployed Teleport Cluster. +--- + +This guide explains how to run the Teleport Kubernetes Operator alongside a Teleport cluster +deployed via the `teleport-cluster` Helm chart. + + +If your Teleport cluster is not deployed using the `teleport-cluster` Helm chart +(Teleport Cloud, manually deployed, deployed via Terraform, ...), you need to follow +[the standalone operator guide](./teleport-operator-standalone.mdx) instead. + + +## Prerequisites + +- Kubernetes cluster (with or without `teleport-cluster` Helm chart already deployed); +- [Helm](https://helm.sh/docs/intro/quickstart/) +- [kubectl](https://kubernetes.io/docs/tasks/tools/) + +Validate Kubernetes connectivity by running the following command: + +```code +$ kubectl cluster-info +# Kubernetes control plane is running at https://127.0.0.1:6443 +# CoreDNS is running at https://127.0.0.1:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy +# Metrics-server is running at https://127.0.0.1:6443/api/v1/namespaces/kube-system/services/https:metrics-server:https/proxy +``` + + + Users wanting to experiment locally with the operator can use [minikube](https://minikube.sigs.k8s.io/docs/start/) + to start a local Kubernetes cluster: + ```code + $ minikube start + ``` + + +## Step 1/3. Install teleport-cluster Helm chart with the operator + +(!docs/pages/kubernetes-access/helm/includes/helm-repo-add.mdx!) + +Install the Helm chart for the Teleport Cluster with `operator.enabled=true` +in the namespace: + + + + +```code +$ helm install teleport-cluster teleport/teleport-cluster \ + --create-namespace --namespace \ + --set clusterName=teleport-cluster.teleport-cluster.svc.cluster.local \ + --set operator.enabled=true \ + --version (=teleport.version=) +``` + + + +Create a namespace for your Teleport cluster resources: + +```code +$ kubectl create namespace +``` + +(!docs/pages/includes//enterprise/obtainlicense.mdx!) + +Create a secret called "license" in the namespace you created: + +```code +$ kubectl -n create secret generic license --from-file=license.pem +``` + +Deploy your Teleport cluster and the Teleport Kubernetes Operator: + +```code +$ helm install teleport-cluster teleport/teleport-cluster \ + --namespace \ + --set enterprise=true \ + --set clusterName=teleport-cluster.teleport-cluster.svc.cluster.local \ + --set operator.enabled=true \ + --version (=teleport.version=) +``` + + + + +This command installs the required Kubernetes CRDs and deploys the Teleport Kubernetes Operator next to the Teleport +cluster. All resources (except CRDs, which are cluster-scoped) are created in the `teleport-cluster` namespace. + +## Step 2/3. Manage Teleport users and roles using `kubectl` + +Create a manifest called `teleport-resources.yaml` that describes two custom resources: a `TeleportUser` and a `TeleportRole`: + +```yaml +apiVersion: resources.teleport.dev/v5 +kind: TeleportRole +metadata: + name: myrole +spec: + allow: + rules: + - resources: ['user', 'role'] + verbs: ['list','create','read','update','delete'] +--- +apiVersion: resources.teleport.dev/v2 +kind: TeleportUser +metadata: + name: myuser +spec: + roles: ['myrole'] +``` + +Apply the manifests to the Kubernetes cluster: + +```code +$ kubectl apply -n -f teleport-resources.yaml +``` + +List the created Kubernetes resources: + +```code +$ kubectl get teleportroles -n +# NAME AGE +# myrole 10m + +$ kubectl get teleportusers -n +# NAME AGE +# myuser 10m +``` + +Check the user `myuser` has been created in Teleport and has been granted the role `myrole`: +```code +$ AUTH_POD=$(kubectl get pods -n -l app=teleport-cluster -o jsonpath='{.items[0].metadata.name}') +$ kubectl exec -it "$AUTH_POD" -c teleport -- tctl users ls +# User Roles +# ----------------------------- ----------------------------- +# bot-teleport-operator-sidecar bot-teleport-operator-sidecar +# myuser myrole +``` + +At this point the Teleport Kubernetes Operator is functional and Teleport users and roles can be managed from +Kubernetes. + +## Step 3/3. Explore the Teleport CRDs + +Available fields can be browsed with `kubectl explain` in a cluster with Teleport CRDs installed. +For example the command: +```code +$ kubectl explain teleportroles.spec +``` +Returns the following fields: +```shell +KIND: TeleportRole +VERSION: resources.teleport.dev/v5 + +RESOURCE: spec + +DESCRIPTION: + Role resource definition v5 from Teleport + +FIELDS: + allow + Allow is the set of conditions evaluated to grant access. + + deny + Deny is the set of conditions evaluated to deny access. Deny takes priority + over allow. + + options + Options is for OpenSSH options like agent forwarding. +``` + +## Troubleshooting + +(!docs/pages/includes/diagnostics/kubernetes-operator-troubleshooting.mdx!) + +## Next steps + +Helm Chart parameters are documented in the [`teleport-cluster` Helm chart reference](../../reference/helm-reference/teleport-cluster.mdx). + +See the [Helm Deployment guides](../../deploy-a-cluster/helm-deployments.mdx) detailing specific setups like running Teleport on AWS or GCP. diff --git a/docs/pages/management/dynamic-resources/teleport-operator-standalone.mdx b/docs/pages/management/dynamic-resources/teleport-operator-standalone.mdx new file mode 100644 index 00000000000..3f666b3db68 --- /dev/null +++ b/docs/pages/management/dynamic-resources/teleport-operator-standalone.mdx @@ -0,0 +1,127 @@ +--- +title: Standalone Kubernetes Operator +description: Run a standalone operator against a remote Teleport cluster such as Teleport Cloud. +--- + +This guide explains how to run the Teleport Kubernetes Operator against any remote Teleport cluster. +If your Teleport cluster is deployed using the `teleport-cluster` Helm chart, you might want to follow +[the guide for Helm-deployed clusters](./teleport-operator-helm.mdx) instead. + +## Prerequisites + +(!docs/pages/includes/self-hosted-prereqs-tabs.mdx!) + +- a Kubernetes cluster. You must be able to create/read Namespace, ServiceAccount, + Deployment, Secret, Role, RoleBinding and CustomResourceDefinition resources. +- [Helm](https://helm.sh/docs/intro/quickstart/) +- [kubectl](https://kubernetes.io/docs/tasks/tools/) + +Validate Kubernetes connectivity by running the following command: + +```code +$ kubectl cluster-info +# Kubernetes control plane is running at https://127.0.0.1:6443 +# CoreDNS is running at https://127.0.0.1:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy +# Metrics-server is running at https://127.0.0.1:6443/api/v1/namespaces/kube-system/services/https:metrics-server:https/proxy +``` + + + Users wanting to experiment locally with the operator can use [minikube](https://minikube.sigs.k8s.io/docs/start/) + to start a local Kubernetes cluster: + ```code + $ minikube start + ``` + + +### Step 1/4 - Create the operator role + +In this step we create the role the operator uses to interact with Teleport resources. + +Download and apply the operator role manifest: + +```bash +$ curl -L -O https://raw.githubusercontent.com/gravitational/teleport/v(=teleport.version=)/integrations/operator/hack/fixture-operator-role.yaml +$ tctl create -f operator-role.yaml +``` + + +If you upgrade the operator to a new version that adds support for new Teleport +resources, you will need to re-apply the operator role manifest. This will grant +the operator access to the new resources. + + +### Step 2/4 - Create the operator join token + +The join token is used by the operator on each startup to join the Teleport cluster and retrieve its client certificates. + +To establish trust between the connecting operator and Teleport, we are delegating the authentication to Kubernetes. Kubernetes has its own internal CA which signs the ServiceAccount tokens that are mounted in the pods. In the following setup, Teleport will trust SA tokens signed by Kubernetes to join the cluster. + +1. Retrieve the Kubernetes JWKS (the keys Teleport can use to validate Kubernetes SA tokens) + ```shell + $ export JWKS="$(kubectl get --raw /openid/v1/jwks)" + ``` +1. Create the token manifest that allows serviceaccount teleport-iac-operator from the namespace teleport-iac to join the cluster as the operator. + ```shell + $ cat < operator-token.yaml + kind: token + version: v2 + metadata: + name: operator-bot + spec: + roles: [Bot] + # bot_name will match the name of the bot created later in this guide. + bot_name: operator + join_method: kubernetes + kubernetes: + type: static_jwks + static_jwks: + jwks: | + $JWKS + allow: + - service_account: "teleport-iac:teleport-iac-operator" # namespace:serviceaccount + EOF + ``` +1. Then, apply the token manifest: + ```shell + $ tctl create -f operator-token.yaml + ``` + +### Step 3/4 - Create the operator bot + +In Teleport, a bot is a resource allowing a machine to access Teleport. +Create a bot for the operator with the following command: + +```shell +$ tctl bots add operator --token operator-bot --role operator +``` + +### Step 4/4 - Deploy the operator in the Kubernetes cluster + +At this point you can configure and run the operator: + +(!docs/pages/kubernetes-access/helm/includes/helm-repo-add.mdx!) + +1. Create the Kubernetes namespace that will contain both the operator Pods and the CustomResources to configure Teleport: + ```shell + $ kubectl create namespace teleport-iac + ``` +1. Apply the strictest Pod Security Standard on the namespace: + ```shell + $ kubectl label namespace teleport-iac 'pod-security.kubernetes.io/enforce=restricted' + ``` +1. Deploy the operator with Helm: + ```shell + $ helm install teleport-iac teleport/teleport-operator -n teleport-iac --set authAddr=teleport.example.com:443 --set token operator-bot + ``` +1. Validate that operator is running properly (the operator might take a few seconds to start): + ``` + $ kubectl get pods -n teleport-iac + ``` + +## Troubleshooting + +(!docs/pages/includes/diagnostics/kubernetes-operator-troubleshooting.mdx!) + +## Next steps + +Helm Chart parameters are documented in the [`teleport-operator` Helm chart reference](../../reference/helm-reference/teleport-operator.mdx). diff --git a/docs/pages/management/dynamic-resources/teleport-operator.mdx b/docs/pages/management/dynamic-resources/teleport-operator.mdx index 893adbb3299..ae4eeb48520 100644 --- a/docs/pages/management/dynamic-resources/teleport-operator.mdx +++ b/docs/pages/management/dynamic-resources/teleport-operator.mdx @@ -11,10 +11,19 @@ can use a Kubernetes client like `kubectl` or their existing CI/CD Kubernetes pi custom resources. The Teleport Kubernetes Operator watches for those resources and does API calls to Teleport to reach the desired state. -The teleport-cluster Helm chart deploys the Teleport Kubernetes Operator as a sidecar in the auth pods.  -The Operator supports multiple auth pod replicas within a single cluster by electing a leader with a Kubernetes lease. -If multiple `teleport-cluster` releases are using the same backend, only one should have the operator enabled. -Multiple operators from different leases will conflict and lock themselves. +Since Teleport version 15, the operator can be deployed both: +- alongside self-hosted Teleport clusters deployed with the `teleport-cluster` Helm chart. + This deployment method differs from version 14. In version 15 and above, the operator + is no longer deployed as a sidecar. An operator outage cannot affect Teleport's availability. +- against a remote Teleport instance (such as Teleport Cloud or deployed with Terraform) + +The operator supports multiple replicas within a single cluster by electing a +leader with a Kubernetes lease. + + +Only one operator deployment should run against a Teleport cluster. Else, different operators +could cause instability and non-deterministic behaviour. + Currently supported Teleport resources are: - users @@ -24,247 +33,18 @@ Currently supported Teleport resources are: - GitHub connectors - Login Rules -This guide covers how to: -- Install Teleport Operator on Kubernetes. -- Manage Teleport users and roles using Kubernetes. +### Setting up the operator -## Prerequisites +If you are self-hosting Teleport using the `teleport-cluster` Helm chart, +follow [the guide for Helm-deployed clusters](./teleport-operator-helm.mdx). -(!docs/pages/includes/self-hosted-prereqs-tabs.mdx!) +If you are hosting Teleport out of Kubernetes (Teleport Cloud, Terraform, ...), +follow [the standalone operator guide](./teleport-operator-standalone.mdx). -- Kubernetes cluster (with or without `teleport-cluster` Helm chart already deployed); -- [Helm](https://helm.sh/docs/intro/quickstart/) -- [kubectl](https://kubernetes.io/docs/tasks/tools/) +### Troubleshooting -Validate Kubernetes connectivity by running the following command: - -```code -$ kubectl cluster-info -# Kubernetes control plane is running at https://127.0.0.1:6443 -# CoreDNS is running at https://127.0.0.1:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy -# Metrics-server is running at https://127.0.0.1:6443/api/v1/namespaces/kube-system/services/https:metrics-server:https/proxy -``` - - - Users wanting to experiment locally with the operator can use [minikube](https://minikube.sigs.k8s.io/docs/start/) - to start a local Kubernetes cluster: - ```code - $ minikube start - ``` - - -## Step 1/3. Install teleport-cluster Helm chart with the operator - -(!docs/pages/kubernetes-access/helm/includes/helm-repo-add.mdx!) - -Install the Helm chart for the Teleport Cluster with `operator.enabled=true`: - - - - -```code -$ helm install teleport-cluster teleport/teleport-cluster \ - --create-namespace --namespace teleport-cluster \ - --set clusterName=teleport-cluster.teleport-cluster.svc.cluster.local \ - --set operator.enabled=true \ - --version (=teleport.version=) -``` - - - -Create a namespace for your Teleport cluster resources: - -```code -$ kubectl create namespace teleport-cluster -``` - -(!docs/pages/includes//enterprise/obtainlicense.mdx!) - -Create a secret called "license" in the namespace you created: - -```code -$ kubectl -n teleport-cluster create secret generic license --from-file=license.pem -``` - -Deploy your Teleport cluster and the Teleport Kubernetes Operator: - -```code -$ helm install teleport-cluster teleport/teleport-cluster \ - --namespace teleport-cluster \ - --set enterprise=true \ - --set clusterName=teleport-cluster.teleport-cluster.svc.cluster.local \ - --set operator.enabled=true \ - --version (=teleport.version=) -``` - - - - -This command installs the required Kubernetes CRDs and deploys the Teleport Kubernetes Operator next to the Teleport -cluster. All resources (except CRDs, which are cluster-scoped) are created in the `teleport-cluster` namespace. - -All subsequent commands will take place in the `teleport-cluster` namespace, so let's use it by default: -```code -$ kubectl config set-context --current --namespace teleport-cluster -``` - -## Step 2/3. Manage Teleport users and roles using `kubectl` - -Create a manifest called `teleport-resources.yaml` that describes two custom resources: a `TeleportUser` and a `TeleportRole`: - -```yaml -apiVersion: resources.teleport.dev/v5 -kind: TeleportRole -metadata: - name: myrole -spec: - allow: - rules: - - resources: ['user', 'role'] - verbs: ['list','create','read','update','delete'] ---- -apiVersion: resources.teleport.dev/v2 -kind: TeleportUser -metadata: - name: myuser -spec: - roles: ['myrole'] -``` - -Apply the manifests to the Kubernetes cluster: - -```code -$ kubectl apply -f teleport-resources.yaml -``` - -List the created Kubernetes resources: - -```code -$ kubectl get teleportroles -# NAME AGE -# myrole 10m - -$ kubectl get teleportusers -# NAME AGE -# myuser 10m -``` - -Check the user `myuser` has been created in Teleport and has been granted the role `myrole`: -```code -$ AUTH_POD=$(kubectl get po -l app=teleport-cluster -o jsonpath='{.items[0].metadata.name}') -$ kubectl exec -it "$AUTH_POD" -c teleport -- tctl users ls -# User Roles -# ----------------------------- ----------------------------- -# bot-teleport-operator-sidecar bot-teleport-operator-sidecar -# myuser myrole -``` - -At this point the Teleport Kubernetes Operator is functional and Teleport users and roles can be managed from -Kubernetes. - -## Step 3/3. Explore the Teleport CRDs - -Available fields can be browsed with `kubectl explain` in a cluster with Teleport CRDs installed. -For example the command: -```code -$ kubectl explain teleportroles.spec -``` -Returns the following fields: -```shell -KIND: TeleportRole -VERSION: resources.teleport.dev/v5 - -RESOURCE: spec - -DESCRIPTION: - Role resource definition v5 from Teleport - -FIELDS: - allow - Allow is the set of conditions evaluated to grant access. - - deny - Deny is the set of conditions evaluated to deny access. Deny takes priority - over allow. - - options - Options is for OpenSSH options like agent forwarding. -``` - -## Troubleshooting - -### Resource is not reconciled in Teleport - -The Teleport Operator watches for new resources or changes in Kubernetes. When a change happens, it triggers the reconciliation -loop. This loop is in charge of validating the resource, checking if it already exists in Teleport and making calls to -the Teleport API to create/update/delete the resource. The reconciliation loop also adds a `status` field on the -Kubernetes resource. - -If an error happens and the reconciliation loop is not successful, an item in `status.conditions` will describe what -went wrong. This allows users to diagnose errors by inspecting Kubernetes resources with `kubectl`: - -```code -$ kubectl get teleportusers myuser -o yaml -``` - -For example, if a user has been granted a nonexistent role the status will look like: - -```yaml -apiVersion: resources.teleport.dev/v2 -kind: TeleportUser -# [...] -status: - conditions: - - lastTransitionTime: "2022-07-25T16:15:52Z" - message: Teleport resource has the Kubernetes origin label. - reason: OriginLabelMatching - status: "True" - type: TeleportResourceOwned - - lastTransitionTime: "2022-07-25T17:08:58Z" - message: 'Teleport returned the error: role my-non-existing-role is not found' - reason: TeleportError - status: "False" - type: SuccessfullyReconciled -``` - -Here `SuccessfullyReconciled` is `False` and the error is `role my-non-existing-role is not found`. - -If the status is not present or does not give sufficient information to solve the issue, check the operator logs: - -```shell -$ kubectl logs "$AUTH_POD" -c operator -``` - - - In case of multi-replica deployments, only one operator instance is running the reconciliation loop. This operator - is called the leader and is the only one producing reconciliation logs. The other operator instances are waiting with - the following log: - - ``` - leaderelection.go:248] attempting to acquire leader lease teleport/431e83f4.teleport.dev... - ``` - - To diagnose reconciliation issues, you will have to inspect all pods to find the one reconciling the resources. - - -### Cluster instability after enabling the Operator - -If enabling the Teleport Kubernetes Operator leads to cluster instability such as degraded proxy state, inability to log into the Teleport cluster, -or loss of access to the Teleport Web UI, check where your Auth Server pods are deployed. All operator sidecars connecting to the same -shared backend must belong to the same `teleport-cluster` chart release to support the leader election process. -Failing to do so can lead to a degraded Teleport cluster and errors such as: - -```text -[AUTH] WARN lock targeting User:"bot-example" is in force: The bot user "bot-teleport-operator-sidecar" -has been locked due to a certificate generation mismatch, possibly indicating a stolen certificate. -``` -In order to resolve this issue, remove any Teleport Kubernetes Operator sidecars connecting to the shared backend that are not in the same -Kubernetes cluster or namespace. Then redeploy the Auth Server pods. When the operator starts, it deletes the cached information and recreates all required resources. +(!docs/pages/includes/diagnostics/kubernetes-operator-troubleshooting.mdx!) ## Next steps -Helm Chart parameters are documented in the [`teleport-cluster` Helm chart reference](../../reference/helm-reference/teleport-cluster.mdx). - -See the [Helm Deployment guides](../../deploy-a-cluster/helm-deployments.mdx) detailing specific setups like running Teleport on AWS or GCP. - Check out [access controls documentation](../../access-controls/introduction.mdx) diff --git a/docs/pages/reference/helm-reference.mdx b/docs/pages/reference/helm-reference.mdx index ed360394231..c4f0a48e23a 100644 --- a/docs/pages/reference/helm-reference.mdx +++ b/docs/pages/reference/helm-reference.mdx @@ -10,6 +10,8 @@ layout: tocless-doc - [teleport-kube-agent](./helm-reference/teleport-kube-agent.mdx): Deploy the Teleport Kubernetes Service, Application Service, or Database Service on Kubernetes. +- [teleport-operator](./helm-reference/teleport-operator.mdx): Deploy the + Teleport Kubernetes Operator. - [teleport-plugin-event-handler](./helm-reference/teleport-plugin-event-handler.mdx): Deploy the Teleport Event Handler plugin which sends events and session logs to Fluentd. diff --git a/docs/pages/reference/helm-reference/includes/zz_generated.teleport-operator.mdx b/docs/pages/reference/helm-reference/includes/zz_generated.teleport-operator.mdx new file mode 100644 index 00000000000..1748ac0bc75 --- /dev/null +++ b/docs/pages/reference/helm-reference/includes/zz_generated.teleport-operator.mdx @@ -0,0 +1,306 @@ + +## `enabled` + +| Type | Default | +|------|---------| +| `bool` | `true` | + +`enabled` controls if the operator should be enabled and deployed. + +- When `true`, the chart creates both the `CustomResourceDefinition` and operator `Deployment` Kubernetes resources. +- When `false`, the chart creates the `CustomResourceDefinition` resources without the operator `Deployment`. + +## `authServer` + +| Type | Default | +|------|---------| +| `string` | `""` | + +`authServer` is the address of the Teleport cluster whose resources are managed +by the operator. The address must contain both the domain name and the port of +the Teleport cluster. It can be either the address of the auth servers or the +proxy servers. + +For example: + - joining a Proxy: `teleport.example.com:443` or `teleport.example.com:3080` + - joining an Auth: `teleport-auth.example.com:3025` + - joining a Cloud-hosted Teleport: `example.teleport.sh:443` + +## `caPins` + +| Type | Default | +|------|---------| +| `list[string]` | `[]` | + +`caPins` is a list of Teleport CA fingerprints that is used by the operator to +validate the identity of the Teleport Auth server. This is only used when joining +an Auth server directly (on port `3025`) and is ignored when joining through a Proxy +(port `443` or `3080`). + +## `joinMethod` + +| Type | Default | +|------|---------| +| `string` | `"kubernetes"` | + +`joinMethod` describes how the Teleport Kubernetes Operator joins the Teleport cluster. +The operator does not store its Teleport-issued identity, it must be able to join the +cluster again on each pod restart. To achieve this, it needs to use a delegated join +method. `kubernetes` is the most common one. + +## `token` + +| Type | Default | +|------|---------| +| `string` | `""` | + +`token` is the name of the token used by the operator to join the Teleport cluster. + +## `teleportVersionOverride` + +| Type | Default | +|------|---------| +| `string` | `""` | + +`teleportVersionOverride` controls the Teleport Kubernetes Operator +image version deployed by the chart. + +Normally, the version of the Teleport Kubernetes Operator matches the +version of the chart. If you install chart version 15.0.0, you'll use +Teleport Kubernetes Operator version 15.0.0. Upgrading the operator is +done by upgrading the chart. + + +`teleportVersionOverride` is intended for development and MUST NOT be +used to control the Teleport version in a typical deployment. This +chart is designed to run a specific Teleport version. You will face +compatibility issues trying to run a different Teleport version with it. + +If you want to run Teleport version `X.Y.Z`, you should use +`helm install --version X.Y.Z` instead. + + + +## `image` + +| Type | Default | +|------|---------| +| `string` | `"public.ecr.aws/gravitational/teleport-operator"` | + +`image` sets the container image used for Teleport Kubernetes Operator +pods run by the chart. + +You can override this to use your own Teleport Kubernetes Operator +image rather than a Teleport-published image. + +## `annotations` + +### `annotations.deployment` + +| Type | Default | +|------|---------| +| `object` | `{}` | + +`annotations.deployment` contains the Kubernetes annotations +put on the `Deployment` resource created by the chart. + +### `annotations.pod` + +| Type | Default | +|------|---------| +| `object` | `{}` | + +`annotations.pod` contains the Kubernetes annotations +put on the `Pod` resources created by the chart. + +### `annotations.serviceAccount` + +| Type | Default | +|------|---------| +| `object` | `{}` | + +`annotations.serviceAccount` contains the Kubernetes annotations +put on the `Deployment` resource created by the chart. + +## `serviceAccount` + +### `serviceAccount.create` + +| Type | Default | +|------|---------| +| `bool` | `true` | + +`serviceAccount.create` controls if the chart should create the Kubernetes +`ServiceAccount` resource for the operator. + +- When `true`, the chart creates a `ServiceAccount` resource for the operator. +- When `false`, the chart does not create the `ServiceAccount` resource. + The user is responsible for deploying and maintaining it separately. + +This value can be set to `false` when deploying in constrained environments +where the user deploying the operator is not allowed to edit `ServiceAccount` +resources. + +### `serviceAccount.name` + +| Type | Default | +|------|---------| +| `string` | `""` | + +`serviceAccount.name` controls the name of the operator Kubernetes `ServiceAccount`. +The operator pods use by default a `ServiceAccount` named after the Helm chart release. +This value overrides this behaviour, this is useful when `serviceAccount.create` +is false and the operator must use an existing `ServiceAccount`. + +## `rbac` + +### `rbac.create` + +| Type | Default | +|------|---------| +| `bool` | `true` | + +`rbac.create` controls if the chart should create RBAC Kubernetes resources. + +- When `true`, the chart creates both `Role` and `RoleBinding` resources for the operator. +- When `false`, the chart does not create the `Role` and `RoleBinding` resources. + The user is responsible for deploying and maintaining them separately. + +This value can be set to `false` when deploying in constrained environments +where the user deploying the operator is not allowed to edit RBAC resources. + +## `imagePullPolicy` + +| Type | Default | +|------|---------| +| `string` | `"IfNotPresent"` | + +`imagePullPolicy` sets the pull policy for any pods created by the chart. +See [the Kubernetes documentation](https://kubernetes.io/docs/concepts/containers/images/#updating-images) +for more details. + +## `resources` + +| Type | Default | +|------|---------| +| `object` | `{}` | + +`resources` sets the resource requests/limits for any pods created by the chart. +See [the Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/) +for more details. + +## `priorityClassName` + +| Type | Default | +|------|---------| +| `string` | `""` | + +`priorityClassName` sets the priority class used by any pods created by the chart. +The user is responsible for creating the `PriorityClass` resource before deploying the chart. +See [the Kubernetes documentation](https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/) +for more details. + +## `tolerations` + +| Type | Default | +|------|---------| +| `list` | `[]` | + +`tolerations` sets the tolerations for any pods created by the chart. +See [the Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) +for more details. + +## `nodeSelector` + +| Type | Default | +|------|---------| +| `object` | `{}` | + +`nodeSelector` sets the node selector for any pods created by the chart. +See [the Kubernetes documentation](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector) +for more details. + +## `affinity` + +| Type | Default | +|------|---------| +| `object` | `{}` | + +`affinity` sets the affinities for any pods created by the chart. +See [the Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity) +for more details. + +## `imagePullSecrets` + +| Type | Default | +|------|---------| +| `list` | `[]` | + +`imagePullSecrets` sets the image pull secrets for any pods created by the chart. +See [the Kubernetes documentation](https://kubernetes.io/docs/concepts/containers/images/#referring-to-an-imagepullsecrets-on-a-pod) +for more details. + +## `highAvailability` + +### `highAvailability.replicaCount` + +| Type | Default | +|------|---------| +| `int` | `1` | + +`highAvailability.replicaCount` controls the amount of operator pod replicas deployed +by the chart. + +When multiple pods are running, all pods join the Teleport cluster on +startup but a single pod actively reconciles resources. + +The operator replicas elect a replica leader using +[Kubernetes leases](https://kubernetes.io/docs/concepts/architecture/leases/). +If the leader fails, its lease will expire and another replica will start +reconciling resources. + +## `tls` + +### `tls.existingCASecretName` + +| Type | Default | +|------|---------| +| `string` | `""` | + +`tls.existingCASecretName` makes the operator pods trust an additional CA certificate. +This is used to trust Proxy certificates if they're signed by a private CA. The operator +trusts by default CAs part of Mozilla's Web PKI (the `ca-certificates` package). + +To use this value, you must create a Kubernetes `Secret` containing the CA +certs in the same namespace as the Teleport Kubernetes Operator using a +command such as: + +```shell +$ kubectl create secret generic my-root-ca --from-file=ca.pem=/path/to/root-ca.pem +``` + +## `podSecurityContext` + +| Type | Default | +|------|---------| +| `object` | `{"fsGroup":65532,"runAsGroup":65532,"runAsNonRoot":true,"runAsUser":65532,"seccompProfile":"RuntimeDefault"}` | + +`podSecurityContext` sets the pod security context for any pods created by the chart. +See [the Kubernetes documentation](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-the-security-context-for-a-pod) +for more details. + +The default value supports running under the `restricted` +[Pod Security Standard](https://kubernetes.io/docs/concepts/security/pod-security-standards/). + +## `securityContext` + +| Type | Default | +|------|---------| +| `object` | `{"allowPrivilegeEscalation":false,"capabilities":{"drop":["ALL"]},"readOnlyRootFilesystem":true}` | + +`securityContext` sets the container security context for any pods created by the chart. +See [the Kubernetes documentation](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-the-security-context-for-a-container) +for more details. + +The default value supports running under the `restricted` +[Pod Security Standard](https://kubernetes.io/docs/concepts/security/pod-security-standards/). diff --git a/docs/pages/reference/helm-reference/teleport-operator.mdx b/docs/pages/reference/helm-reference/teleport-operator.mdx new file mode 100644 index 00000000000..b552532a507 --- /dev/null +++ b/docs/pages/reference/helm-reference/teleport-operator.mdx @@ -0,0 +1,27 @@ +--- +title: teleport-operator Chart Reference +description: Values that can be set using the teleport-operator Helm chart +--- + +The `teleport-operator` Helm chart deploys the Teleport Kubernetes Operator. +When deployed via the chart, the operator can join Teleport clusters living in +Kubernetes or remote ones (such as Teleport Cloud). +See the [Kubernetes Operator for remote Teleport clusters guide](../../management/dynamic-resources/teleport-operator-standalone.mdx) +for more details. + +You can +[browse the source on GitHub](https://github.com/gravitational/teleport/tree/branch/v(=teleport.major_version=)/examples/chart/teleport-cluster/charts/teleport-operator). + + +The `teleport-operator` chart was introduced in Teleport 15. Prior versions don't +support running the operator separately from the `teleport-cluster` chart. + + + +The chart is versioned with the Teleport Kubernetes Operator. No compatibility +guarantees are ensured if the operator and chart versions differ. +It is strongly recommended to always align the chart and operator versions +by using the `--version` Helm flag. + + +(!docs/pages/reference/helm-reference/includes/zz_generated.teleport-operator.mdx!) diff --git a/examples/chart/Makefile b/examples/chart/Makefile index 35cce795ccf..064e3939a02 100644 --- a/examples/chart/Makefile +++ b/examples/chart/Makefile @@ -1,7 +1,7 @@ # TODO(hugoShaka): uncomment the additional targets as we start sync-ing # the reference and the values.yaml .PHONY: render-chart-ref -render-chart-ref: render-chart-ref-example # render-chart-ref-teleport-cluster render-chart-ref-teleport-kube-agent render-chart-ref-teleport-operator +render-chart-ref: render-chart-ref-example render-chart-ref-teleport-operator # render-chart-ref-teleport-cluster render-chart-ref-teleport-kube-agent .PHONY: render-chart-ref-example render-chart-ref-example: @@ -11,26 +11,26 @@ render-chart-ref-example: # .PHONY: render-chart-ref-teleport-cluster # render-chart-ref-teleport-cluster: # cd ../../build.assets/tooling && \ -# go run ./cmd/render-helm-ref -chart ../../examples/chart/teleport-cluster/ -output ../../docs/pages/reference/helm-reference/include/zz_generated.teleport-cluster.mdx +# go run ./cmd/render-helm-ref -chart ../../examples/chart/teleport-cluster/ -output ../../docs/pages/reference/helm-reference/includes/zz_generated.teleport-cluster.mdx # # # .PHONY: render-chart-ref-teleport-kube-agent # render-chart-ref-teleport-kube-agent: # cd ../../build.assets/tooling && \ -# go run ./cmd/render-helm-ref -chart ../../examples/chart/teleport-kube-agent/ -output ../../docs/pages/reference/helm-reference/include/zz_generated.teleport-kube-agent.mdx +# go run ./cmd/render-helm-ref -chart ../../examples/chart/teleport-kube-agent/ -output ../../docs/pages/reference/helm-reference/includes/zz_generated.teleport-kube-agent.mdx # -# .PHONY: render-chart-ref-teleport-operator -# render-chart-ref-teleport-operator: -# cd ../../build.assets/tooling && \ -# go run ./cmd/render-helm-ref -chart ../../examples/chart/teleport-operator/ -output ../../docs/pages/reference/helm-reference/include/zz_generated.teleport-operator.mdx +.PHONY: render-chart-ref-teleport-operator +render-chart-ref-teleport-operator: + cd ../../build.assets/tooling && \ + go run ./cmd/render-helm-ref -chart ../../examples/chart/teleport-cluster/charts/teleport-operator -output ../../docs/pages/reference/helm-reference/includes/zz_generated.teleport-operator.mdx .PHONY: check-chart-ref -check-chart-ref: check-chart-ref-example #check-chart-ref-teleport-cluster check-chart-ref-teleport-kube-agent check-chart-ref-teleport-operator +check-chart-ref: check-chart-ref-example check-chart-ref-teleport-operator #check-chart-ref-teleport-cluster check-chart-ref-teleport-kube-agent .PHONY: check-chart-ref-example check-chart-ref-example: - echo "Checking example chart reference" - cd ../../build.assets/tooling && \ + @echo "Checking example chart reference" + @cd ../../build.assets/tooling && \ go run ./cmd/render-helm-ref -chart ./cmd/render-helm-ref/testdata -output - | diff ../../build.assets/tooling/cmd/render-helm-ref/testdata/expected-output.mdx - || \ echo "Chart values.yaml and reference differ, please run 'make render-chart-ref'" @@ -38,19 +38,19 @@ check-chart-ref-example: # check-chart-ref-teleport-cluster: # echo "Checking teleport-cluster reference" # cd ../../build.assets/tooling && \ -# go run ./cmd/render-helm-ref -chart ../../examples/chart/teleport-cluster -output - | diff ../../docs/pages/reference/helm-reference/include/zz_generated.teleport-cluster.mdx - || \ +# go run ./cmd/render-helm-ref -chart ../../examples/chart/teleport-cluster -output - | diff ../../docs/pages/reference/helm-reference/includes/zz_generated.teleport-cluster.mdx - || \ # echo "Chart values.yaml and reference differ, please run 'make render-chart-ref'" # # .PHONY: check-chart-ref-teleport-kube-agent # check-chart-ref-teleport-kube-agent: # echo "Checking teleport-kube-agent reference" # cd ../../build.assets/tooling && \ -# go run ./cmd/render-helm-ref -chart ../../examples/chart/teleport-kube-agent -output - | diff ../../docs/pages/reference/helm-reference/include/zz_generated.teleport-kube-agent.mdx - || \ +# go run ./cmd/render-helm-ref -chart ../../examples/chart/teleport-kube-agent -output - | diff ../../docs/pages/reference/helm-reference/includes/zz_generated.teleport-kube-agent.mdx - || \ # echo "Chart values.yaml and reference differ, please run 'make render-chart-ref'" # -# .PHONY: check-chart-ref-teleport-operator -# check-chart-ref-teleport-operator: -# echo "Checking teleport-operator reference" -# cd ../../build.assets/tooling && \ -# go run ./cmd/render-helm-ref -chart ../../examples/chart/teleport-cluster/charts/teleport-operator -output - | diff ../../docs/pages/reference/helm-reference/include/zz_generated.teleport-operator.mdx - || \ -# echo "Chart values.yaml and reference differ, please run 'make render-chart-ref'" +.PHONY: check-chart-ref-teleport-operator +check-chart-ref-teleport-operator: + @echo "Checking teleport-operator reference" + @cd ../../build.assets/tooling && \ + go run ./cmd/render-helm-ref -chart ../../examples/chart/teleport-cluster/charts/teleport-operator -output - | diff ../../docs/pages/reference/helm-reference/includes/zz_generated.teleport-operator.mdx - || \ + echo "Chart values.yaml and reference differ, please run 'make render-chart-ref'" diff --git a/examples/chart/teleport-cluster/charts/teleport-operator/values.yaml b/examples/chart/teleport-cluster/charts/teleport-operator/values.yaml index 8f65f658cce..ab01a966056 100644 --- a/examples/chart/teleport-cluster/charts/teleport-operator/values.yaml +++ b/examples/chart/teleport-cluster/charts/teleport-operator/values.yaml @@ -1,50 +1,179 @@ +# enabled(bool) -- controls if the operator should be enabled and deployed. +# +# - When `true`, the chart creates both the `CustomResourceDefinition` and operator `Deployment` Kubernetes resources. +# - When `false`, the chart creates the `CustomResourceDefinition` resources without the operator `Deployment`. enabled: true +# authServer(string) -- is the address of the Teleport cluster whose resources are managed +# by the operator. The address must contain both the domain name and the port of +# the Teleport cluster. It can be either the address of the auth servers or the +# proxy servers. +# +# For example: +# - joining a Proxy: `teleport.example.com:443` or `teleport.example.com:3080` +# - joining an Auth: `teleport-auth.example.com:3025` +# - joining a Cloud-hosted Teleport: `example.teleport.sh:443` authServer: "" + +# caPins(list[string]) -- is a list of Teleport CA fingerprints that is used by the operator to +# validate the identity of the Teleport Auth server. This is only used when joining +# an Auth server directly (on port `3025`) and is ignored when joining through a Proxy +# (port `443` or `3080`). caPins: [] + +# joinMethod(string) -- describes how the Teleport Kubernetes Operator joins the Teleport cluster. +# The operator does not store its Teleport-issued identity, it must be able to join the +# cluster again on each pod restart. To achieve this, it needs to use a delegated join +# method. `kubernetes` is the most common one. joinMethod: "kubernetes" + +# token(string) -- is the name of the token used by the operator to join the Teleport cluster. token: "" +# teleportVersionOverride(string) -- controls the Teleport Kubernetes Operator +# image version deployed by the chart. +# +# Normally, the version of the Teleport Kubernetes Operator matches the +# version of the chart. If you install chart version 15.0.0, you'll use +# Teleport Kubernetes Operator version 15.0.0. Upgrading the operator is +# done by upgrading the chart. +# +# +# `teleportVersionOverride` is intended for development and MUST NOT be +# used to control the Teleport version in a typical deployment. This +# chart is designed to run a specific Teleport version. You will face +# compatibility issues trying to run a different Teleport version with it. +# +# If you want to run Teleport version `X.Y.Z`, you should use +# `helm install --version X.Y.Z` instead. +# +# teleportVersionOverride: "" nameOverride: "" fullNameOverride: "" -# Kubernetes Teleport Operator image +# image(string) -- sets the container image used for Teleport Kubernetes Operator +# pods run by the chart. +# +# You can override this to use your own Teleport Kubernetes Operator +# image rather than a Teleport-published image. image: public.ecr.aws/gravitational/teleport-operator +# annotations -- annotations: + # annotations.deployment(object) -- contains the Kubernetes annotations + # put on the `Deployment` resource created by the chart. deployment: {} + # annotations.pod(object) -- contains the Kubernetes annotations + # put on the `Pod` resources created by the chart. pod: {} + # annotations.serviceAccount(object) -- contains the Kubernetes annotations + # put on the `Deployment` resource created by the chart. serviceAccount: {} +# serviceAccount -- serviceAccount: + # serviceAccount.create(bool) -- controls if the chart should create the Kubernetes + # `ServiceAccount` resource for the operator. + # + # - When `true`, the chart creates a `ServiceAccount` resource for the operator. + # - When `false`, the chart does not create the `ServiceAccount` resource. + # The user is responsible for deploying and maintaining it separately. + # + # This value can be set to `false` when deploying in constrained environments + # where the user deploying the operator is not allowed to edit `ServiceAccount` + # resources. create: true + # serviceAccount.name(string) -- controls the name of the operator Kubernetes `ServiceAccount`. + # The operator pods use by default a `ServiceAccount` named after the Helm chart release. + # This value overrides this behaviour, this is useful when `serviceAccount.create` + # is false and the operator must use an existing `ServiceAccount`. name: "" +# rbac -- rbac: + # rbac.create(bool) -- controls if the chart should create RBAC Kubernetes resources. + # + # - When `true`, the chart creates both `Role` and `RoleBinding` resources for the operator. + # - When `false`, the chart does not create the `Role` and `RoleBinding` resources. + # The user is responsible for deploying and maintaining them separately. + # + # This value can be set to `false` when deploying in constrained environments + # where the user deploying the operator is not allowed to edit RBAC resources. create: true +# imagePullPolicy(string) -- sets the pull policy for any pods created by the chart. +# See [the Kubernetes documentation](https://kubernetes.io/docs/concepts/containers/images/#updating-images) +# for more details. imagePullPolicy: IfNotPresent +# resources(object) -- sets the resource requests/limits for any pods created by the chart. +# See [the Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/) +# for more details. resources: {} +# priorityClassName(string) -- sets the priority class used by any pods created by the chart. +# The user is responsible for creating the `PriorityClass` resource before deploying the chart. +# See [the Kubernetes documentation](https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/) +# for more details. priorityClassName: "" +# tolerations(list) -- sets the tolerations for any pods created by the chart. +# See [the Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) +# for more details. tolerations: [] +# nodeSelector(object) -- sets the node selector for any pods created by the chart. +# See [the Kubernetes documentation](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector) +# for more details. nodeSelector: {} +# affinity(object) -- sets the affinities for any pods created by the chart. +# See [the Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity) +# for more details. affinity: {} +# imagePullSecrets(list) -- sets the image pull secrets for any pods created by the chart. +# See [the Kubernetes documentation](https://kubernetes.io/docs/concepts/containers/images/#referring-to-an-imagepullsecrets-on-a-pod) +# for more details. imagePullSecrets: [] +# highAvailability -- highAvailability: + # highAvailability.replicaCount(int) -- controls the amount of operator pod replicas deployed + # by the chart. + # + # When multiple pods are running, all pods join the Teleport cluster on + # startup but a single pod actively reconciles resources. + # + # The operator replicas elect a replica leader using + # [Kubernetes leases](https://kubernetes.io/docs/concepts/architecture/leases/). + # If the leader fails, its lease will expire and another replica will start + # reconciling resources. replicaCount: 1 +# tls -- tls: + # tls.existingCASecretName(string) -- makes the operator pods trust an additional CA certificate. + # This is used to trust Proxy certificates if they're signed by a private CA. The operator + # trusts by default CAs part of Mozilla's Web PKI (the `ca-certificates` package). + # + # To use this value, you must create a Kubernetes `Secret` containing the CA + # certs in the same namespace as the Teleport Kubernetes Operator using a + # command such as: + # + # ```shell + # $ kubectl create secret generic my-root-ca --from-file=ca.pem=/path/to/root-ca.pem + # ``` existingCASecretName: "" +# podSecurityContext(object) -- sets the pod security context for any pods created by the chart. +# See [the Kubernetes documentation](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-the-security-context-for-a-pod) +# for more details. +# +# The default value supports running under the `restricted` +# [Pod Security Standard](https://kubernetes.io/docs/concepts/security/pod-security-standards/). podSecurityContext: seccompProfile: RuntimeDefault runAsUser: 65532 @@ -52,6 +181,12 @@ podSecurityContext: fsGroup: 65532 runAsNonRoot: true +# securityContext(object) -- sets the container security context for any pods created by the chart. +# See [the Kubernetes documentation](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-the-security-context-for-a-container) +# for more details. +# +# The default value supports running under the `restricted` +# [Pod Security Standard](https://kubernetes.io/docs/concepts/security/pod-security-standards/). securityContext: allowPrivilegeEscalation: false capabilities: