Revisit Application Connector tests

[janmedrek]

Description

We need to provide a clear suite of tests that will go through all the functionalities that Application Connector presents.
Right now we have multiple tests that run through the same scenario and test the same code.

The desired state would be to have:

• a FIT scenario that goes through the whole flow available without Compass and testing available Application Gateway auth methods
  • called either from lambda via internal eventing (presents some coupling to the Serverless and Eventing area)
  • called from within a cluster with regular call
• a FIT scenario that goes through Compass integration, tests the whole registration flow with Commerce Mock, sends an event through the mTLS gateway, and checks whether the external API of Commerce Mock can be called (make sure the cleanup is done properly in Compass)
• A test checking the functionalities of Application Gateway (proxying, various auth methods available - we could introduce mocks here for checking different methods)
• A test checking whether Applications are properly synchronized by the Compass Runtime Agent (we can use the static Compass tenant and just check if Compass Runtime Agent downloaded and applied the proper YAML)
• A test checking Connectivity Validator functionality (consider using a static TLS certificate and just sending a request there)

ad 1) we have multiple Octopus tests in Go that should be removed as they are no longer used (#13338)
ad 2) we need to clean up old prow pipelines (#11870)

Reasons

A clear test structure and responsibility division will reduce maintenance effort and provide better quality for the area. It will be transparent which components fail and which require some attention.

Acceptance Criteria

• Mentioned test cases implemented
• Unnecessary tests removed
• Testing should take minimal possible execution time
• Tests implemented should be easily maintainable

[Disper]

This testing strategy draft documentation might be somehow relevant.

[janmedrek]

I have updated the test cases - with the modularization on the horizon we want to make sure that tests for the Application Connector module are separated.

[VOID404]

Gateway Tests PR: #1450

[akgalwas]

The test project will be comprised of three test-suites:

• Application Gateway
• Connectivity Validator
• Compass Runtime Agent

The following requirements were defined for the test project structure:

• It will be added here: https://github.com/kyma-project/kyma/tree/main/tests/components
• There will be separate subfolder for each test-suite
• There will be separate image built for each test-suite
• Each test-suite subfolder will contain all the manifests and code needed by the testsuite

[akgalwas]

The general idea for testing Application Gateway is as follows:

• There will be a simple Go application covering all supported authentication methods.
• The test application will be deployed in the Kyma cluster and access Central Application Gateway via internal k8s service
• Test will be comprised of the following:
  • Go application using go test
  • k8s manifests containing Applications CRDs, secrets and RBAC resources needed to execute test application in the k8s cluster
• Test cases should be defined in Application CRD. There should be one service entry for each authentication method. We should strive to make code minimal.

Additional requirements:

• In order to simplify design the test app should use the same secrets Application Gateway uses.
• Test App should be configured with Config Map

Idea: test app could be a part of the test binary. It simplifies setup and allows to avoid the need for synchronising test and test app startup.

[akgalwas]

The general test-cases to cover in Application Gateway test-suite:

• Authorisation related:
  • Positive authorisation for each method supported (BasicAuth, OAuth, etc.)
  • Authorisation failed for each method supported (BasicAuth, OAuth, etc.). Note: it needs to be discussed as from App Gateway perspective it is the same case as above.
  • OAuth specific: token renewal
• Path related:
  • Application name and service name not provided in the path
  • Service name missing in the path
  • Path segments added to the target path. Example: there is an API under some URL (e.g. 'my-cool-api.com') registered in Application CRD. The user calls App Gateway URL and specifies a specific endpoint in the target API (e.g. central-application-gateway.kyma-integration:8080/<app>/<service>/some/endpoint). As a result the following URL is called: my-cool-api.com/some/endpoint
• Kubernetes resources related:
  • Application name specified in the path doesn't exist
  • Service name specified in the path doesn't exist
  • Secret containing credentials doesn't exist
• Proxying related:
  • Response code from target service returned
  • Response body from target service returned
  • Call to target API timeouts

[akgalwas]

Authorisation methods supported by Application Gateway:

• no authorisation
• Basic Auth
• OAuth (grant client credentials flow)
• OAuth protected with mTLS (please see Implement mtls oauth token fetch #14401)
• mTLS (a.k.a CertGen)
• CSRF with:
  • no authorisation
  • Basic Auth
  • OAuth (grant client credentials flow)
  • OAuth protected with mTLS
  • mTLS

In addition the following may be added by Application Gateway:

• Additional headers
• Additional query parameters

Note: mind that for CSRF the same authorisation method is used for target API and CSRF token endpoint.

[akgalwas]

Work plan:

• 1. Prepare and merge initial PR with test project structure (Rewrite Central Gateway tests in Go #14504). (In progress) @VOID404
• 2. Prepare initial structure of test app and merge it into test project structure. Implement minimal set of test-cases. (In progress) @mvshao Ac test test app #14582
• 3. Implement pipeline for testing Application Gateway. @koala7659 (New pipelines for testing application-connector components test-infra#5563).
• 4. Implement supported authentication methods in test application.
• 5. Implement all test-cases in Application Gateway test-suite
• 6. Prepare initial design for Connectivity Validator test-suite. @akgalwas
• 7. Implement Connectivity Validator test-suite. @akgalwas
• 8. Implement pipeline for testing Connectivity Validator.
• 9. Prepare initial design for Compass Runtime Agent test-suite. - PR @franpog859
• 10. Implement Compass Runtime Agent test-suite.
• 11. Implement pipeline for testing Compass Runtime Agent.
• 12. Clean up useless tests. - PR1, PR2 @franpog859
• 13. Tests should be ran automatically on release branches

[janmedrek]

@VOID404, @mvshao please separate the following cases into linked GH issues:

• Application Gateway tests + pipeline
• Connectivity Validator tests + pipeline
• Compass Runtime Agent tests + pipeline

You can also move the above comments from @akgalwas to those issues, and keep this one transparent as a collective epic for a new test suite for the whole area. 🙂

[franpog859]

The Application Gateway tests are done, @janmedrek

[franpog859]

I created a follow-up issue #15666 for this one #15037 as we wanted to first create an integration test that enables us to abandon the manual release testing and then enhance the tests with all of the additional CRA responsibilities checks

[kyma-bot]

This issue or PR has been automatically marked as stale due to the lack of recent activity.
Thank you for your contributions.

This bot triages issues and PRs according to the following rules:

• After 60d of inactivity, lifecycle/stale is applied
• After 7d of inactivity since lifecycle/stale was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Close this issue or PR with /close

If you think that I work incorrectly, kindly raise an issue with the problem.

/lifecycle stale