* Add support for Kubernetes discovery into kube agent helm chart
* Remove requiring namespaces and labels
* Remove wrong default values for roles.
* Make sure we fail fast if app role enabled but nothing related to it actually set
* Remove unneeded 'and'
Co-authored-by: Tiago Silva <tiago.silva@goteleport.com>
* Improve wording.
Co-authored-by: Hugo Shaka <hugo.hervieux@goteleport.com>
* Clarify when discovery service is enabled
Co-authored-by: Hugo Shaka <hugo.hervieux@goteleport.com>
* Change indent
Co-authored-by: Hugo Shaka <hugo.hervieux@goteleport.com>
* Add kubernetesDiscovery field to values.schema.json
* Change name of the feature in readme
---------
Co-authored-by: Tiago Silva <tiago.silva@goteleport.com>
Co-authored-by: Hugo Shaka <hugo.hervieux@goteleport.com>
* add option to force re-authentication for OIDC connectors
* expose max_age directly
* update comment for MaxAge, regen operator manifests to make linter happy
* make max_age nullable
* make max_age a duration
* use google.protobuf.Duration
* Revert "use google.protobuf.Duration"
This reverts commit e6c3b7deaf9ffebb33492e3b6e575289e3ad1c37.
* make it more clear that max age is a full duration
* document how MaxAge duration is represented
* rebuild operator manifests
* integrations/crdgen: Support loading instructions from a file for easier debugging
* integrations/crdgen: Fix CRD generation for nested message declarations
* integrations/crdgen: Update CRDs and CRD snaphots after crdgen fix
* integrations/operator: Add a test covering machineID on GHA tokens
* document how to dump protoc requests
* Allow creating a admin `ClusterRoleBinding`
This PR adds the possibility of creating a cluster role binding between a group whose name defined by `adminClusterRolebinding.name` and the built-in `cluster-admin` `ClusterRole`.
This is particularly useful for GKE Autopilot clusters where it's not
possible to use the default `system:masters` group because authz Warden
security module prevents impersonating system-wide identities.
When the chart detects that the target cluster is a GKE cluster - `version: v1.x.x-gke.<build>` - it will automatically create the `ClusterRoleBinding` and print a warning message with the following payload:
```
NOTES:
WARNING: GKE Autopilot clusters forbid users from impersonating system-wide identities.
This means you won't be able to use the `system:masters` Kubernetes Group in
the Teleport Roles for GKE Autopilot clusters.
Given that you installed Teleport on a GKE cluster, we recommend you use the
Kubernetes Group `cluster-admin` instead of `system:masters` in the Teleport Roles
for GKE Autopilot clusters.
This chart automatically created the `cluster-admin` Kubernetes Group for you and
assigned it admin privileges on the Kubernetes cluster.
Consult the built-in security features that GKE Autopilot enforces:
https://cloud.google.com/kubernetes-engine/docs/concepts/autopilot-security#built-in-security
```
Part of #28506
Signed-off-by: Tiago Silva <tiago.silva@goteleport.com>
* Apply suggestions from code review
Co-authored-by: Gus Luxton <gus@goteleport.com>
* add role example
---------
Co-authored-by: Gus Luxton <gus@goteleport.com>
This PR fixes the operator's CRDs drift between the CRD and the proto
stubs they are derived from.
It also adds a check to prevent future drifts by forcing the manifest
generation and requiring an empty diff.
Fixes#29438
* Use the examples directory for example plugin code
Also edit the Access Request plugin API guide to use this directory,
rather than having the reader copy/paste individual code snippets. This
makes the guide easier to follow, and users will have a compilable
example before they proceed through the guide.
* Run make fix-license
* Run make fix-imports
* Fix spelling
* Run go mod tidy
* Extract Access Request plugin example to partials
This way, we can reuse the actual program in the Access Request plugin
API guide and avoid unintended discrepancies and drift.
* Use types.Events.NewWatcher instead of watcherjob
Need to test this out, but it compiles
* Remove outdated information
- Types that are no longer reachable via public interfaces
- The description of the demo implementation that used the old
`watcherjob` package
* Update text to reflect new `run` logic
* Make the example program more modular
Respond to Joerger feedback
* Respond to alexfornuto feedback
* Apply suggestions from code review
Co-authored-by: Brian Joerger <bjoerger@goteleport.com>
* Respond to zmb3 feedback
- Split up "types.go". Reserve a single file for configuration values so
these are visible in a single place within the guide.
- Return an error on an unsuccessful HTTP request when creating or
updating a row
- Simplify requestStates lookup
- Clearly mark values that a user must change
- Update the text of the guide to match changes to the program
* Spell fixes
* Respond to zmb3 feedback
---------
Co-authored-by: Brian Joerger <bjoerger@goteleport.com>
When the script detects throttling it automatically scales the RCU,
however it was allowing the RCU to reach 0 which is an invalid
value. Any subsequent requests with a 0 RCU end up terminating the
script due to errors from the request. The RCU is no capped at a
minimum value of 1 to prevent this.
CredentialsChainVerboseErrors is now set in the aws.Config to provide
more actionable error messages when credentials are not configured
correctly. Users who had authentication issues would previously see
the following:
> 2023/07/11 16:50:25 NoCredentialProviders: no valid providers in chain. Deprecated.
> For verbose messaging see aws.Config.CredentialsChainVerboseErrors
By setting the config value to true users will now see more detailed output:
> 2023/07/12 10:56:06 NoCredentialProviders: no valid providers in chain
> caused by: EnvAccessKeyNotFound: failed to find credentials in the environment.
> SharedCredsLoad: failed to load profile, .
> EC2RoleRequestError: no EC2 instance role found
> caused by: RequestError: send request failed
The README was also updated to include instructions on how to authenticate
and run the script from outside the Auth server if they so choose.
* helm: Add ingress template
* helm: Add ingress support
With the changes introducing automatic websocket upgrades for TLS routing in Teleport 13, we can finally add support for a Kubernetes ingress.
* Remove unnecessary brackets
* Tidying
* Gating
* Fix lint and schema
* Fix lint examples
* Handle wildcards
* Tidy up wildcard support
* Don't add AWS annotations when using ingress
* Update AWS docs to use Ingress/ALB with ACM
* Automatically listens on 443, make values simpler
* Support ingress.spec overrides
* Enable ingress and set spec.ingressClassName
* Update values schema
* typo
* Whitelist 'healthcheck' for spellcheck
* Address Hugo's comments from code review
* Apply Paul's comments from code review
* Few more docs fixes
* Update teleport-cluster reference
* Add values file and fix lint/tests
* Fix docs lint
* Add proxy_service.trust_x_forwarded_for when ingress is enabled and Teleport version >=14
* Fix semver check for pre-releases
* Indent ingress section correctly
* Address docs feedback from Hugo/Tiago
* Add warning about using tsh with ingress
* Fix lint spelling
* Add instructions for checking AWS LB controller installation
* Whitelist ingressclass in spellcheck
* What a stupid error
* update to not be SSH-specific
* hard breaks ~80 chars
* undo changes from d80ab5b...
I had adjusted this section to fit as a prereq bullet point. It makes more sense for this to be a unique section at the bottom of SSO pages, so that the reader only changes the default auth method _after_ completing the setup.
* update onelogin SSO guide
* Respond to @ptgott's feedback
* Promote IAC docs for agents and dynamic resources
Closes#27382Closes#25418Closes#25442
Two aspects of setting up a Teleport cluster are omnipresent in the docs
but never get dedicated treatment:
- Running agents
- Applying dynamic resources
As a result, it is difficult to include discussions about those topics
that are separate from a specific workflow or how-to guide. One glaring
absence has been prominent guidance on using infrastructure-as-code
tools to achieve these tasks.
This change improves the visibility of Teleport's support for
infrastructure-as-code tools by:
- Creating top-level docs sections for running agents and applying
dynamic resources
- Making IAC instructions prominent within these sections
The intention is for readers to become familiar with different methods
of applying dynamic resources and running agents, including how to do
this with IAC, so they can apply this knowledge when reading other parts
of the docs.
As a result, in the docs sidebar, the "Dynamic Resources" section comes
before the section on RBAC, and the "Teleport Agents" section comes
before the sections related to individual Teleport services
("Application Access", "Server Access", etc.).
The new section on dynamic resources also gives us a place to put other
guides to using the Terraform provider and Kubernetes Operator, e.g., if
we add guides to using these tools with popular GitOps platforms.
Likewise, the section on agents gives us a place to put other agent-wide
information, e.g., how to enable an additional Teleport service on an
instance that is already running.
To allow for these changes, I have also made the following, more
tangentially related sidebar changes:
- **Renamed sidebar sections to be noun phrases instead of verb
phrases:** Currently, one half of the sidebar is made of imperative
phrases like "Manage Access" and "Manage your Cluster". This doesn't
really work for the sections on agents and dynamic resources, so I
have renamed these sections for consistency.
- **Moved the "Manage your Cluster" and "Deploy a Cluster" sections**: I
have arranged the sidebar so more basic topics (i.e., those that new
users and experienced users alike will need to be familiar with) are
on the top and more advanced ones are on the bottom.
The other sections that are currently in the first half of the sidebar
are topics that all Teleport users will need to get familiar with,
while day two operations and self-hosted production deployments are
more advanced topics.
- **Edited the landing page:** I have edited the landing page of the
docs to reflect the new sidebar organization. This also makes the page
shorter, simpler, and more opinionated. It spells out a high-level
sequence for setting up Teleport, then provides a list of advanced
topics for further reading.
Links correspond to sidebar sections--as before, I wanted to describe
the topic of each sidebar section so users would know this information
without having to navigate away from the landing page.
* Move the "Dynamic Configuration" section
Make this a subsection of "Manage your Cluster" since it's not
self-evidently clear as a top-level docs section. Users will probably
need an introduction via the "Manage your Cluster" section intro page.
This also reverts some of the more drastic sidebar changes introduced by
the previous commit.
Responds to xinding33 feedback.
* Make IAC learning tracks prominent/hard to avoid
Closes#27751
Responds to xinding33 feedback
The motivation is to be more opinionated about the course that users
take through the docs. We currently recommend two tracks for
self-service users, i.e., the users expected to make use of the landing
page:
- Setting up a toy self-hosted Teleport cluster
- Setting up a Teleport Team/Enterprise Cloud cluster that can
eventually become production ready
By moving the "Get Started" guide to the landing page, we direct users
immediately on to the first track. This change then gives new users a
way to enter the second track from the docs landing page with a
prominent link to the Teleport Team docs.
This change also edits The landing page to direct users who have
completed the getting started experience to instructions for setting up
a pool of agents on Terraform, helping to make infrastructure-as-code a
first-class citizen of the docs.
This change also removes the menu of links that used to confront users
on the landing page. Since all sidebar sections include introduction
pages, users interested in the content of a sidebar section can visit
the section. By removing links, we make it clearer for users how to
proceed through the docs.
* Fix linter errors
* Incorporate Trivy recommendations
* Respond to alexfornuto feedback
* Restore list of dynamic resources to the reference
* Fix linter warnings
* Remove the ".sh" extension from userdata script
The Terraform module that reads this file does not need the extension,
which was causing trouble for our shellcheck linter.
* k8s operator supports Okta import rules.
The k8s operator now supports Okta import rules, which will allow users to
use native k8s CRDs to provision Okta import rules in k8s environments.
* Fix helm test.
* Remove unneeded proto files.
* Use additionalProperties in the okta import rules CRD instead of properties.
This is the result of running `make manifests` in integrations/operator
to update the CRDs with the latest role spec definition, which includes
label expressions.
* helm: Add conditional RBAC/ServiceAccount to post-delete hook
* Add unit tests
* Remove unnecessary documentIndex
* Template service account name
* Additional fixes for service account name
* Add unit test for default case
* Order isn't important
* Fix documentIndex
* Remove blanket snapshots and tidy up documentIndex
* Clean up comments on documentIndex
* Update to Readme for Teleport Usage
Cleaning up the Readme. Removing the prompt option as it is no longer an option. Also clarifying where to find the container image version. Lastly, reordered the docker command to be backwards compatible on Docker.
* Update examples/teleport-usage/README.md
Co-authored-by: Zac Bergquist <zac.bergquist@goteleport.com>
* Update examples/teleport-usage/README.md
Co-authored-by: Zac Bergquist <zac.bergquist@goteleport.com>
---------
Co-authored-by: Zac Bergquist <zac.bergquist@goteleport.com>
