opensource/teleport
3
0
Fork 0
mirror of https://github.com/gravitational/teleport.git synced 2026-09-24 16:17:11 +08:00
Code Issues Packages Projects Releases Wiki Activity

docs: standalone Teleport operator (#34801)

Browse Source
This commit is contained in:
Hugo Shaka
2023-12-06 15:39:15 +00:00
committed by GitHub
parent a57c65549b
commit 2fb6043a0e
15 changed files with 931 additions and 278 deletions
Download Patch File Download Diff File Expand all files Collapse all files
build.assets/tooling/cmd/render-helm-ref/main.go
+10 -5
View File
@@ -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
}
build.assets/tooling/cmd/render-helm-ref/template.go
+4 -1
View File
@@ -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))
build.assets/tooling/cmd/render-helm-ref/testdata/expected-output.mdx
Vendored
+10
View File
@@ -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 |
build.assets/tooling/cmd/render-helm-ref/testdata/values.yaml
Vendored
+6
View File
@@ -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.
docs/config.json
+22 -10
View File
@@ -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/"
docs/pages/access-controls/login-rules/kubernetes.mdx
+3 -3
View File
@@ -39,10 +39,10 @@ This guide is applicable if you self-host Teleport in Kubernetes using the
</Admonition>
- 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:
docs/pages/includes/diagnostics/kubernetes-operator-troubleshooting.mdx
+60
View File
@@ -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/<OPERATOR_DEPLOYMENT_NAME>
```
<Admonition type="note">
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.
</Admonition>
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.
docs/pages/management/dynamic-resources/teleport-operator-helm.mdx
+180
View File
@@ -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.
<Admonition type="warning">
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.
</Admonition>
## 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
```
<Admonition type="tip">
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
```
</Admonition>
## 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 <Var name="teleport-cluster"/> namespace:
<Tabs>
<TabItem scope="oss" label="Teleport Community Edition">
```code
$ helm install teleport-cluster teleport/teleport-cluster \
--create-namespace --namespace <Var name="teleport-cluster"/> \
--set clusterName=teleport-cluster.teleport-cluster.svc.cluster.local \
--set operator.enabled=true \
--version (=teleport.version=)
```
</TabItem>
<TabItem scope="enterprise" label="Teleport Enterprise">
Create a namespace for your Teleport cluster resources:
```code
$ kubectl create namespace <Var name="teleport-cluster"/>
```
(!docs/pages/includes//enterprise/obtainlicense.mdx!)
Create a secret called "license" in the namespace you created:
```code
$ kubectl -n <Var name="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 <Var name="teleport-cluster"/> \
--set enterprise=true \
--set clusterName=teleport-cluster.teleport-cluster.svc.cluster.local \
--set operator.enabled=true \
--version (=teleport.version=)
```
</TabItem>
</Tabs>
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 <Var name="teleport-cluster"/> -f teleport-resources.yaml
```
List the created Kubernetes resources:
```code
$ kubectl get teleportroles -n <Var name="teleport-cluster"/>
# NAME AGE
# myrole 10m
$ kubectl get teleportusers -n <Var name="teleport-cluster"/>
# 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 <Var name="teleport-cluster"/> -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 <Object>
DESCRIPTION:
Role resource definition v5 from Teleport
FIELDS:
allow <Object>
Allow is the set of conditions evaluated to grant access.
deny <Object>
Deny is the set of conditions evaluated to deny access. Deny takes priority
over allow.
options <Object>
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.
docs/pages/management/dynamic-resources/teleport-operator-standalone.mdx
+127
View File
@@ -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
```
<Admonition type="tip">
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
```
</Admonition>
### 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
```
<Admonition type="note">
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.
</Admonition>
### 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 <<EOF > 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).
docs/pages/management/dynamic-resources/teleport-operator.mdx
+20 -240
View File
@@ -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.
<Admonition type="warning">
Only one operator deployment should run against a Teleport cluster. Else, different operators
could cause instability and non-deterministic behaviour.
</Admonition>
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
```
<Admonition type="tip">
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
```
</Admonition>
## 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`:
<Tabs>
<TabItem scope="oss" label="Teleport Community Edition">
```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=)
```
</TabItem>
<TabItem scope="enterprise" label="Teleport Enterprise">
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=)
```
</TabItem>
</Tabs>
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 <Object>
DESCRIPTION:
Role resource definition v5 from Teleport
FIELDS:
allow <Object>
Allow is the set of conditions evaluated to grant access.
deny <Object>
Deny is the set of conditions evaluated to deny access. Deny takes priority
over allow.
options <Object>
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
```
<Admonition type="note">
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.
</Admonition>
### 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)
docs/pages/reference/helm-reference.mdx
+2
View File
@@ -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.
docs/pages/reference/helm-reference/includes/zz_generated.teleport-operator.mdx
+306
View File
@@ -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.
<Admonition type="warning">
`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.
</Admonition>
## `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/).
docs/pages/reference/helm-reference/teleport-operator.mdx
+27
View File
@@ -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).
<Admonition type="note" title="Version requirement">
The `teleport-operator` chart was introduced in Teleport 15. Prior versions don't
support running the operator separately from the `teleport-cluster` chart.
</Admonition>
<Admonition type="warning" title="Version Compatibility">
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.
</Admonition>
(!docs/pages/reference/helm-reference/includes/zz_generated.teleport-operator.mdx!)
examples/chart/Makefile
+18 -18
View File
@@ -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'"
examples/chart/teleport-cluster/charts/teleport-operator/values.yaml
+136 -1
View File
@@ -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.
#
# <Admonition type="warning">
# `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.
#
# </Admonition>
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: