* Add IsUsageBased to features and send to web UI
* Update flag name
* Improve comment
* Add comments and improve field name
* Remove duplicated property
* Use `cloud/stable` when Automatic Upgrades is on.
Teleport provides scripts to install teleport agents/services.
Those scripts use YUM/DEB repositories when possible.
Each repo has multiple channels:
- stable/v11
- stable/v12
- cloud/stable
We want to ensure that if the cluster is running in the cloud and
automatic upgrades is on (auth service was started with
TELEPORT_AUTOMATIC_UPGRADES=yes teleport ...), then the installation
script must offer the `cloud/stable` channel.
This PR changes the following scripts:
- Discover Install Node
- Discover Install Database Service
- Install App script
- EC2 default-installer and EC2 default-agentless-installer
* add helm chart knobs to enable auto updater
* use let instead of const and remove default export
* add HA to helm chart
* always return .automatic_upgrades in web ping response
* rename cloud/stable to stable/cloud
* fix ts test
* Add Plugins feature flag
* Add config for plugins runtime
* Allow reading OAuth secrets from files
* Rename Plugins to HostedPlugins
Make it clear that this is separate from the upcoming
self-hosted, standalone plugins that will be part of the Teleport
binary.
* Only allow to read client credentials from files
- When user registers or resets, when running into
policy errors, we don't send back an error, but instead
a 200 (to indicate user has successfully registered/resetted)
and a flag to determine if policy was enabled
- Send back policy configurations for cluster config,
this will allow the web UI login page to just display
redirection messages without login attempts
- For role configured policy, login attempts will be
required and a specific error will be returned so that
the UI can then better redirect the user
Update metalinter, fix a few lint warnings and replace deprecated linters.
`deadcode`, `structcheck` and `varcheck` are abandoned and now replaced by [`unused`][1].
Since 1.19, `go fmt` reformats godocs according to https://go.dev/doc/comment. I've done a bulk-reformatting of the codebase to keep the linter happy. Backporting is mostly harmless (the exception being `lib/services/role_test.go`, that for some reason breaks the _old_ linter using the new format).
[1]: https://golangci-lint.run/usage/linters/
* Bump golangci-lint version
* Replace abandoned linters
* Fix bodyclose on lib/auth/github.com
* Fix bodyclose on lib/kube/proxy/streamproto/proto_test.go
* Fix bodyclose on lib/srv/alpnproxy/proxy_test.go
* Fix bodyclose on lib/web/conn_upgrade_test.go
* Silence staticcheck on lib/kube/proxy/forwarder_test.go
* Silence staticcheck on lib/utils/certs_test.go
* Address BuildNameToCertificate deprecation warnings
* Run `go fmt ./...`
* Run `go fmt ./...` on api/
* Ignore formatting in role_test.go
* Remove redundant initializers in lib/srv/uacc/
* Update e/
* Add Machine ID enterprise license enforcement
This adds two checks to Machine ID for license enforcement: one on
initial bot create, and another on join.
* Use modules.SetTestModules(); fix failing test
Forbids the use of the `--insecure` mode when FIPS mode is enabled in teleport
Disables the `--insecure` tsh command line option when built with FIPS support
See-Also: #5073
Implements RFD #7https://github.com/gravitational/teleport/blob/master/rfd/0007-rbac-oss.md
OSS users can use roles. Some FedRamp related role options
are limited to enterprise.
All users are migrated to a new role "ossuser".
This role is a limited access role downgrading all users
from OSS role "admin".
All trusted clusters are mapped to "ossuser" as well.
Github connector maps teams to generated roles.
For transition period, format `tctl users add alice` works
alongside with `tctl users add alice --roles=admin`, but prints
a warning.
With OSS version and without using the github connector (only local
auth), logged in user won't have any `kubernetes_groups`. Without
usernames too, user can login but can't use kubectl.
This commit fixes#3369, refs #3374
It adds support for kuberenetes_users section in roles,
allowing Teleport proxy to impersonate user identities.
It also extends variable interpolation syntax by adding
suffix and prefix to variables and function `email.local`:
Example:
```yaml
kind: role
version: v3
metadata:
name: admin
spec:
allow:
# extract email local part from the email claim
logins: ['{{email.local(external.email)}}']
# impersonate a kubernetes user with IAM prefix
kubernetes_users: ['IAM#{{external.email}}']
# the deny section uses the identical format as the 'allow' section.
# the deny rules always override allow rules.
deny: {}
```
Some notes on email.local behavior:
* This is the only function supported in the template variables for now
* In case if the email.local will encounter invalid email address,
it will interpolate to empty value, will be removed from resulting
output.
Changes in impersonation behavior:
* By default, if no kubernetes_users is set, which is a majority of cases,
user will impersonate themselves, which is the backwards-compatible behavior.
* As long as at least one `kubernetes_users` is set, the forwarder will start
limiting the list of users allowed by the client to impersonate.
* If the users' role set does not include actual user name, it will be rejected,
otherwise there will be no way to exclude the user from the list).
* If the `kuberentes_users` role set includes only one user
(quite frequently that's the real intent), teleport will default to it,
otherwise it will refuse to select.
This will enable the use case when `kubernetes_users` has just one field to
link the user identity with the IAM role, for example `IAM#{{external.email}}`
* Previous versions of the forwarding proxy were denying all external
impersonation headers, this commit allows 'Impesrsonate-User' and
'Impersonate-Group' header values that are allowed by role set.
* Previous versions of the forwarding proxy ignored 'Deny' section of the roles
when applied to impersonation, this commit fixes that - roles with deny
kubernetes_users and kubernetes_groups section will not allow
impersonation of those users and groups.
Added "--fips" flag to "teleport start" command which can start
Enterprise in FedRAMP/FIPS 140-2 mode.
In FIPS mode, Teleport configures the TLS and SSH servers with FIPS
compliant cryptographic algorithms. In FIPS mode, if non-compliant
algorithms are chosen, Teleport will fail to start. In addition,
Teleport checks if the binary was compiled against an approved
cryptographic module (BoringCrypto) and fails to start if it was not.
If a client, like tsh, tries to use non-FIPS encryption, like NaCl,
those requests are also rejected.
