* Machine ID: Terraform Cloud joining
This adds a new `terraform` join method, which uses Terraform Cloud's
Workload Identity OIDC provider to provide delegated joining support
for Machine ID bots. As the Terraform provider now embeds tbot, this
means - with some light modifications - that the Terraform provider
can now join using this join method, and without any secrets.
* Address some review feedback, add first batch of tests
This addresses a few feedback items, defaulting the audience to the
Teleport cluster name and requiring allow rules specify an
organization + at least one other parameter.
Also, adds a first batch of tests.
* Update autogenerated CRD docs
* Add tests for RegisterUsingToken and provisioning token init
* Fix imports
* Fix CRD docs
* Update tfschema
* Update tf docs
* Update docstring to make it clear that `Audience` is optional
* Update manifests
* Update CRD docs
* Code review feedback; docstring fixes
* Rename lib/terraform to lib/terraformcloud
* Rename terraform -> terraform_cloud
Renames the new join method to terraform_cloud to make it clear that
it won't work for TF running elsewhere (where other join methods
should be used)
* Fix tests and docs lints
* Update api/proto/teleport/legacy/types/types.proto
Co-authored-by: Tiago Silva <tiago.silva@goteleport.com>
* Update proto artifacts
---------
Co-authored-by: Tiago Silva <tiago.silva@goteleport.com>
* Introduce the `tctl terrafor env` command
* fix tests
* address marco's feedback + use correct b64 lib
* add license
* add created-by label as specified in the RFD
* Update tool/tctl/common/terraform_command.go
Co-authored-by: Roman Tkachenko <roman@goteleport.com>
* Apply suggestions from code review
Co-authored-by: Roman Tkachenko <roman@goteleport.com>
* Have telpeort create the Terraform default role
* rename use-existing-role -> role, and stop hijacking identity.SSHCACertBytes
* Make the terraform provider role a real preset, rename to 'terraform-provider'
* lint
* Fix tbot's invocation after rebase
---------
Co-authored-by: Roman Tkachenko <roman@goteleport.com>
* dont allow disabling second factor
* update docs for 2fa change
* add environmental variable to work around disabled 2fa
* check if its cloud
* update todos
* add a test
* introduce insecure test mode
* fixes for tests
* TLS routing connection upgrade using native websocket
* update ut in api
* lib/web/UT update
* fix typo, lint and race
* deal with subprotocol negotiation
* review comments round 1
* fix lint?
* add UT and address some other comments
* add env var to toggle mode
* fix lint
* Add initial future assume role to access requests
* Add assume time on to tsh request show
* Update tool/tsh/common/tsh.go
Co-authored-by: STeve (Xin) Huang <xin.huang@goteleport.com>
* Rename assume-time to assume start time
* Fix tctl request assume-start-time to work when not set
* Add check to check request assumeStartTime is not far in the future
* Add example formats examples to assume-start-time flag
* Omit empty assum_start_time field when serializing access requests
* Update lib/auth/auth.go
Co-authored-by: Zac Bergquist <zac.bergquist@goteleport.com>
* Rename MaxAssumeStartTime to MaxAssumeStartDuration
---------
Co-authored-by: STeve (Xin) Huang <xin.huang@goteleport.com>
Co-authored-by: Zac Bergquist <zac.bergquist@goteleport.com>
This PR removes from the Teleport codebase the following deprecated
code:
- Kubernetes Secret storage compatibility layer: This piece of code was
introduced in Teleport 11 to help users migrating from on-disk
credentials storage to Kubernetes secret storage. Since then, all
users should already migrated to Kube secret storage and it's no
longer needed.
- Expected `no kubernetes_users/kubernetes_groups` error message:
The error message changed in Teleport 13 and was left for compatiblity
reasons since Auth server supported `kubernetes_services` running
`v12.x.x`.
- References to `kube.` SNI prefix for Kube access
Signed-off-by: Tiago Silva <tiago.silva@goteleport.com>
tsh shows clusters alerts for both `tsh login` and `tsh status`.
We intentionally used a short (500ms) timeout to avoid slowing down
`tsh status` which was previously an "offline" command.
As a side effect, cluster alerts would not always show on login if
they took longer than 500ms to fetch.
This change ensures that we always wait for cluster alerts to come
back for `tsh login`, but we still enforce a short timeout for the
`tsh status` command. (The timeout was increased slightly since the
context now wraps the entire command and not just the cluster alerts
call)
Fixes#25239
* Simplify Okta assignment statuses.
The Okta assignment statuses have been simplfieid so that there's only a
status on the Okta assignment object itself and the number of states is
reduced.
* Fix tests, remove unused code.
* Add in Duration for update statuses to prevent changing status too soon.
* Make sure LastTransition is UTC.
* Remove actions in favor of targets, make cleanup time non-nullable.
* ALPN connect test improvements
* fix typos
* remove extra period
* simplify error check
* moving things over
* tsh dials
* reverse tunnel
* fix auth connect
* move ping
* add ssh support
* add HTTP client support
* Move ALPN dialer, ALPN conn upgrade, Ping conn to api
* beatify
* add test
* beautify round 2
* fix timeout
* Implement alpn-ping upgrade for reversetunnel and ssh
* clean up
* fix proxy test
* minor refactor
* remove WebProxyAddr
* require IsALPNConnUpgradeRequiredFunc
* add tlsRoutingWithConnUpgradeConnect
* fix lint
* simplify
* remove debug log and change unknown upgrade type to 404
* Force new proxy client to use web proxy when TLS routing is enabled
* Add new status to OktaAssignment, supporting service methods.
Threee new status have been added to OktaAssignment:
1. PROCESSING indicates that the Okta service is currently acting on this
assignment resource.
2. NEEDS_CLEANUP indicates that the Okta service should clean up this
assignment resource.
3. CLEANUP_PROCESSING indicates that the Okta service us currently acting on
cleaning up this assignment resource.
In addition, the Okta backend services and protobuf have been updated so that
the action statuses for an OktaAssignment object can be set and updated in a
locking way so that multiple processes are able to update action statuses
without the risk of a race condition.
* Update okta_service.proto comments.
* Fix service_test.go
* Allow node to handle old and new way of client IP propagation on same listener
With addition of signed PROXY headers, node was listening on multiplexer, but because
of that it couldn't processing incoming connection from older proxies
when ProxyHelloSignature was used, because
both ends were waiting for the other side to send data first.
Here we integrate ability to handle PROXY headers into connection itself,
so we can start ssh server without waiting for multiplexer to detect connection
* Remove unneeded code
* Improve comment's wording
Co-authored-by: Michael Wilson <mike@mdwn.dev>
* Improve comment's wording
Co-authored-by: Michael Wilson <mike@mdwn.dev>
* Fix imports
* Unexport function
* Add godoc
* Remove unneeded comment
* Move ProxyHelloSignature to constants
* Check that proxyline is verified
* Use Warn() instead of Warnf()
* Move ProxyHelloSignature to api/constants
* Add timeout for getting host CA during proxyline verification.
* Rearrange conditions
Co-authored-by: Edoardo Spadolini <edoardo.spadolini@goteleport.com>
* Clarify comment.
---------
Co-authored-by: Michael Wilson <mike@mdwn.dev>
Co-authored-by: Edoardo Spadolini <edoardo.spadolini@goteleport.com>
The DatabaseService was using the KeepAlive_Database type instead
of a new dedicated type. This caused the keepalive to fail because
the backend key that was created didn't actually exist which results
in #21454.
This adds the appropriate KeepAlive type and uses it in the appropriate
places.
Fixes#21454
* WIP adding OpenSSH CA
* fix creating OpenSSH CA for tests
* fix a test name and tctl usage flag
* fix 'tctl status' not displaying openssh CA sometimes
* add OpenSSH CA to TestInit_bootstrap, remove TLS key pair
* add OpenSSH CA to a few more places
* make help text of 'tctl auth rotate' more helpful and accurate
* fix web cert export test
* tbot doesn't need to know about OpenSSH CA
* address feedback
* fix comment formatting
This PR presents a watcher for automatic `kube_cluster` discovery for GCP GKE clusters. Given an identity with access to the GCP cloud, the auto-discovery service will scan the cloud and register all clusters available in Kubernetes Engine.
Once the discovery service creates a `kube_cluster` on the Auth Server, the Kubernetes Service will start serving it. The credentials used to access the cluster are short-lived and generated through Google OAuth2 associated with the GCP Service Account configured for the Kubernetes Service.
GCP's Service Account must have the following role def attached:
```yaml
description: 'GKE Auto-Discovery'
includedPermissions:
- container.clusters.impersonate
- container.clusters.get
- container.clusters.list
- container.pods.get
- container.selfSubjectAccessReviews.create
- container.selfSubjectRulesReviews.create
name: projects/{projectID}/roles/GKEKubernetesAutoDisc
stage: GA
title: GKEKubernetesAutoDisc
```
Part of #16135, #13376
Related to #12048, #16276, #16281, #16633, #14991
* Detect if HTTP_PROXY/HTTPS_PROXY is specified in `tsh proxy ssh`
* Support HTTPS_PROXY in `tsh proxy ssh`
* Ensure we tidy up connections on failure
* Lintering
This PR presents a watcher for automatic `kube_cluster` discovery for AWS EKS clusters. Given a user with access to the AWS cloud, the auto-discovery service will scan the cloud and register all clusters available in EKS.
Once the discovery service creates a `kube_cluster` on the Auth Server, the Kubernetes Service will start serving it. The credentials used to access the cluster are short-lived - TTL is 15m - and are generated through the IAM role associated with the process running the `kubernetes_service`.
All clusters must necessarily allow access to the Teleport service by configuring the IAM role in the `configmap/aws-auth` present in the `kube-system` namespace. Without this access, the clusters will not be served correctly.
# Future work
- Support GCP auto-discovery
Part of #16135, #13376
Related to #12048, #16276, #16281, #16633
In “tsh login” show only alerts with on-login label.
In “tsh status” show only alerts with “high” severity. Which license warning should match.
In all “tctl” commands show only alerts with “high” severity.
This PR presents a watcher for automatic `kube_cluster` discovery for Azure AKS clusters. Given a user with access to the Azure cloud, the auto-discovery service will scan the cloud and register all clusters available in AKS .
Once the discovery service creates a `kube_cluster` in Auth Server, the Kubernetes Service will start serving it. The credentials used to access the cluster depend on the different AKS clusters configurations:
# Authentication
## Local Accounts
If the AKS cluster auth is based on local accounts created during the provisioning phase of the cluster, the agent will use the [`aks:ListClusterUserCredentials`](https://learn.microsoft.com/en-us/rest/api/aks/managed-clusters/list-cluster-user-credentials?tabs=HTTP) endpoint.
This endpoint returns a `kubeconfig` fully populated with user credentials that Teleport can use to access the cluster.
## AZ Active Directory
When AZ active directory integration is enabled, Azure allows login with AD users. Azure forces the login to happen with dynamic short-lived user tokens. These tokens are generated by calling `credentials.GetToken` with a fixed Scope: `6dae42f8-4368-4678-94ff-3960e28e3630` and with the cluster's `tenant_id`. The token contains the user details as well as `group_ids` to match with authorization rules.
```go
// getAzureToken generates an authentication token for clusters with AD enabled.
func (a *aKSClient) getAzureToken(ctx context.Context, tentantID string, clientCfg *rest.Config) (time.Time, error) {
const (
azureManagedClusterScope = "6dae42f8-4368-4678-94ff-3960e28e3630"
)
cred, err := a.azIdentity(&azidentity.DefaultAzureCredentialOptions{
TenantID: tentantID,
})
if err != nil {
return time.Time{}, trace.Wrap(ConvertResponseError(err))
}
cliAccessToken, err := cred.GetToken(ctx, policy.TokenRequestOptions{
// azureManagedClusterScope is a fixed scope that identifies azure AKS managed clusters.
Scopes: []string{azureManagedClusterScope},
},
)
if err != nil {
return time.Time{}, trace.Wrap(ConvertResponseError(err))
}
// reset the old exec provider credentials
clientCfg.ExecProvider = nil
clientCfg.BearerToken = cliAccessToken.Token
return cliAccessToken.ExpiresOn, nil
}
```
# Authorization
## Local Accounts
The [`aks:ListClusterUserCredentials`](https://learn.microsoft.com/en-us/rest/api/aks/managed-clusters/list-cluster-user-credentials?tabs=HTTP) endpoint returns credentials with enough permissions for Teleport to enroll the cluster.
## AZ AD
### Azure RBAC
When Azure RBAC mode is enabled, the cluster authorization is based on rules specified in the Azure Identity permissions.
The AZ group associated with the AZ identity the Teleport Process is running has to define the following permissions:
```json
{
"Name": "AKS Teleport Discovery Permissions",
"Description": "Required permissions for Teleport auto-discovery.",
"Actions": [],
"NotActions": [],
"DataActions": [
"Microsoft.ContainerService/managedClusters/pods/read",
"Microsoft.ContainerService/managedClusters/users/impersonate/action",
"Microsoft.ContainerService/managedClusters/groups/impersonate/action",
"Microsoft.ContainerService/managedClusters/serviceaccounts/impersonate/action",
"Microsoft.ContainerService/managedClusters/authorization.k8s.io/selfsubjectaccessreviews/write",
"Microsoft.ContainerService/managedClusters/authorization.k8s.io/selfsubjectrulesreviews/write",
],
"NotDataActions": [],
"assignableScopes": [
"/subscriptions/{subscription_id}"
]
}
```
If correctly specified, the Azure authentication service automatically grants access to any cluster within `subscription_id`
without any other definition. On the other hand, if it's incorrectly configured, an error is triggered but Teleport cannot gain access to the cluster.
### Kubernetes RBAC
If AZ RBAC integration is disabled, the authorization to the cluster is processed by Kubernetes RBAC. This is done by matching the Az Identity principals (`group_ids`) with `Role`, `ClusterRole` objects that live in the AKS cluster. This mode requires that the `ClusterRole` and `ClusterRoleBinding` must exist and must be well configured for each cluster to enroll.
```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: teleport-role
rules:
- apiGroups:
- ""
resources:
- users
- groups
- serviceaccounts
verbs:
- impersonate
- apiGroups:
- ""
resources:
- pods
verbs:
- get
- apiGroups:
- "authorization.k8s.io"
resources:
- selfsubjectaccessreviews
- selfsubjectrulesreviews
verbs:
- create
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: teleport-role-binding
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: teleport-role
subjects:
- kind: Group
name: {group_name}
apiGroup: rbac.authorization.k8s.io
```
#### `ClusterRole` and `ClusterRoleBinding` configured
If cluster operators or previous Teleport run has configured access to the cluster, no further action is required since Teleport already has access to the cluster.
#### Cluster `aks:ListClusterAdminCredentials` returns valid credentials
If the Teleport process has access to [`aks:ListClusterAdminCredentials`](https://learn.microsoft.com/en-us/rest/api/aks/managed-clusters/list-cluster-admin-credentials?tabs=HTTP) and the endpoint returns valid cluster admin credentials, Teleport will automatically create the `ClusterRole` and `ClusterRoleBinding` objects in the cluster configured to the `group_id` that is listed in the access token. In order to extract the `group_id` from the token, Teleport parses the JWT claims and extracts the first element.
If the object creation was successful, Teleport can access it, otherwise, it will use the `aks:BeginRunCommand` method to try to configure access to itself.
#### Cluster `aks:BeginRunCommand` returns valid credentials
When we reach this mode, Teleport tries to run a `kubectl` command against the cluster to configure the `ClusterRole` and `ClusterRoleBinding`. `aks:BeginRunCommand` allows any user with access to that endpoint to run arbitrary commands in the cluster (commands cannot be validated). Teleport will use it as the last resource to configure the access to itself.
If the command failed, Teleport cannot grant access to the cluster and an error is returned.
# UX
Currently, to discover AKS resources created and to have them dynamically served by the `kubernetes_service`one can define the following configuration.
```yaml
discovery_service:
enabled: true
azure:
- subscriptions: ["*"]
types: ["aks"]
regions: ["*"]
tags:
'*': '*'
kubernetes_service:
enabled: true
resources:
labels:
'*': '*'
```
# Future work
- Support AWS dynamic authentication
Part of #16135, #13376
Related to #12048, #16276, #16281
Address TODOs, add deprecation warnings and remove as many U2F code references
as possible.
Existing behavior is kept unaltered: it's still possible to inform Teleport of
old U2F AppIDs and U2F configurations are still silently converted to WebAuthn.
There's no reason to break that, so we don't.
Most server-side references to SecondFactorU2F are removed, but client-side
references remain: this makes it possible to interop newer clients with old
clusters (something else may break, but hopefully not this part).
Closes#10375.
* Add initial version of installer
* Resolve comments
- Use aws waiters when checking commands
- Use SSMRunRequest rather than passing instances
- General comments
* Resolve comments, (rebase) pass scriptname parameter
This resolves comments regarding running on multiple ec2 instances at
once by adding state to the instances cache to check if the instance
is known about and how far into installation it is
* Revert cache
* Dont cache on non discovery nodes
* Resolve some comments
* Move discovery out to its own serviec
* Add a `discovery_service` section
* Fix messed up conflict merge
* Make starting a standalone discovery agent work
* Resolve comments
* Resolve comments
- use a regular events.Emitter
- resolve a thousand typos :)
* Resolve comments
* resolve comments, fix a bad merge
* Fail when a non ec2 matcher type is configured
* fix lint-go
* Resolve comments
* Resolve comments, add initial test (currently broken)
* Fix log string so only 1 pair of [] are used
* Chunk instances for sending commands
* add 'isInitialized' to watchers
* Add test for chunked discovery, log output
* lints
* explicetly set matcher.Tags to "*":"*" if its unset
* WebAPI: update user traits
Web API only supports updating the roles property for a given User.
This PR adds the possibility of updating User's traits
- Logins
- DB Users
- DB Names
- Kube Users
- Kube Groups
- Windows Logins
- AWS Role ARNs
It only updates if the requests contains a non-nil value for the trait's
list.
It deduplicates the trait's list before applying it.
Gavin Frazar