* add Redshift Serverless e2e tests
* update license year in new files
* use a test cleanup func to close local proxy
* adjust test timeouts
* use a longer conn retry interval
* add AWS RDS MariaDB e2e tests
* fix spurious teardown error logs
* if a role or user doesn't exist, that is not an error nor is it worth
logging during auto user teardown.
* check for admin option
* add some extra secret fetching checkings
* only drop redshift user if the user exists
* update AWS RDS db e2e tests
* update GHA workflow env vars to be RDS specific
* add auto db user provisioning tests
* provision any db users needed in test code as setup, instead of
relying on the cloud-terraform repo provisioning them
* fix data race
* rename myDBName to mysqlDBName
* fix flakiness on first run
* remove db_users for auto user roles
* test role assignments in postgres
* reuse rand string util
* test role assignments in mysql
* rearrange subtests to clearly outline dependencies
* verify AWS CA when provisioning
* fix imports
* Remove account lockout from failed recovery attempts
This account lockout looks to be unecessary and potentially problematic. Recovery codes and recovery through MFA are not possible to brute force.
In addition the potential to lockout an account from being able to use a recovery method could result in them being unable to unlock their account from other potential abuse cases (for example an attacker locking the account from failed password attempts).
As discussed in the RFD (https://github.com/gravitational/teleport/pull/35533) this includes the removal of all the API used for this locking mechanism.
* accountrecovery: Update `WithLock` function names
* accountrecovery: Combine verifyRecoveryCode and verifyRecoveryCodeWithRecord into one function
* Further GRPC cleanup after PR feedback
* Apply PR Feedback
* Reorganize process config test fields
* Move PollingPeriod back from Testing field
* Fix comment text
Co-authored-by: Nic Klaassen <nic@goteleport.com>
---------
Co-authored-by: Nic Klaassen <nic@goteleport.com>
* Remove use of require assertions inside Eventually calls
require.Eventually runs the predicate function in a background
goroutine. It is invalid to use require to make assertions
inside the eventually, because require will fail the test if the
assertion fails, and tests can only be failed from the test's
main goroutine.
* Use EventuallyWithT
* test RDS database discovery
* test RDS postgres instance connection
* organize some common test helpers for eks/rds e2e tests
* exclude e2e tests from flaky test base step
* exclude e2e tests in other test flows
* skip e2e db tests by default via env var check
* add postgres web conn test
* Add end-to-end tests with Playwright
This commit introduces end-to-end tests with Docker Compose to improve code quality and provide a more robust testing environment. This involves adding a GitHub workflow for manually triggering the test suite, Makefile commands for running, the tests, and configurations. This addition will enable easier testing and provide a platform for future test development.
* Cleanup
* Only allow manual CI trigger
* Ignore e2e tests in Jest configuration
Added 'testPathIgnorePatterns' field to the Jest configuration in order to ignore end-to-end tests when running unit tests.
* Address code review comments
* Update e2e test environment for multi-architecture support
Modified the end-to-end test setup scripts and docker files to support both Linux and MacOS architectures. The build process now detects the system architecture and downloads the appropriate version of `mkcert`. Also, there is a control flow to build binaries only if they don't exist and the build files are now mounted from the build directory instead of being copied. These changes aim to make the e2e tests more robust and adaptable to different development environments.
* Update Makefile and teleport.yaml for testing improvements
Continued refinement of testing process by updating the Makefile and teleport.yaml. Changes to the Makefile include additional phony targets, modification of build-binaries, and a new 'all' target which runs key steps in sequence. The teleport.yaml file was updated to version v3.
* Fix makefile on MacOS
* Add Readme
After merging #28845, the cluster name is different and the test failed.
Since the AWS E2E tests are not required, the merge happened and broke
all tests.
Signed-off-by: Tiago Silva <tiago.silva@goteleport.com>
This PR enables AWS E2E integration tests for EKS auto-discovery.
This process uses Github's OIDC connector to access AWS API by assuming the `arn:aws:iam::307493967395:role/tf-aws-e2e-gha-role` role.
```yaml
- name: Configure AWS Credentials
uses: aws-actions/configure-aws-credentials@v2
with:
aws-region: ${{ env.AWS_REGION }}
role-to-assume: ${{ env.GHA_ASSUME_ROLE }}
```
`aws-actions/configure-aws-credentials` action generates a new ID token with the information required and signs it using Github's OIDC workflow.
The role `arn:aws:iam::307493967395:role/tf-aws-e2e-gha-role` is an intermediate role for the runner to be able to assume two distinct roles:
- `arn:aws:iam::307493967395:role/tf-eks-discovery-ci-cluster-kubernetes-service-access-role` - used by Kubernetes Service
- `arn:aws:iam::307493967395:role/tf-eks-discovery-ci-cluster-discovery-service-access-role` - used by Discovery Service
The Discovery service will assume role `arn:aws:iam::307493967395:role/tf-eks-discovery-ci-cluster-discovery-service-access-role` which defines the following policy:
- `eks:ListClusters`
- `eks:DescribeCluster`
These are the minimal permissions required to list the available clusters and retrieve their state and labels.
Teleport Discovery Service will pull the EKS cluster available and for each cluster to import, it will create a `kube_cluster` object in Auth Server.
Once the cluster is discovered and the `kube_cluster` exists in Auth server, the Teleport Kubernetes Service will start proxying the cluster.
For that, it must pull the cluster API endpoint and its CA data to create a client. Role `arn:aws:iam::307493967395:role/tf-eks-discovery-ci-cluster-kubernetes-service-access-role` allows Kubernetes Service to describe the cluster and retrieve its details.
- `eks:DescribeCluster`
The IAM role used by the Kubernetes Service must be mapped to a Kubernetes Group that allows impersonation in order to be able to proxy requests with the user's permissions.
```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
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: teleport-crb
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: teleport-role
subjects:
- kind: Group
name: ${group_name}
```
During the cluster provisioning phase, we mapped the Kubernetes Service IAM role into a Kubernetes Group ` ${group_name}`.
```yaml
mapRoles:
- groups:
- ${group_name}
rolearn:arn:aws:iam::307493967395:role/tf-eks-discovery-ci-cluster-kubernetes-service-access-role
username: "eleport:{{SessionName}}
```
The final step is to validate the client is working correctly and that the Kubernetes Service was able to generate a valid token that can impersonate Kubernetes groups and users.
For that, we simulate a user calling `kubectl get services -n default` through Teleport that must return 1 entry, the default service `kubernetes`.
Implements #27156
Gavin Frazar