Integration development environment

[adam-cattermole]

Added new make commands to:

• Deploy kind cluster with the wasm_shim compile target mapped as a volume
• Install authorino-operator
• Deploy authorino + certs based on TLS_ENABLED
• Deploy limitador
• Deploy envoyproxy with the local volume mapped
• Deploys talker-api
• Deploys simple authconfig and secret for the API key user-guide

To deploy all of the above:

make local-setup

Cleanup:

make local-cleanup

To test changes to the wasm binary you can simply run the following to redeploy in the cluster:

make build local-rollout

To watch the envoy + wasm logs:

kubectl logs -f deployment/envoy

To test the API:

kubectl port-forward --namespace default deployment/envoy 8000:8000

curl -H "Host: test.a.auth.com" http://127.0.0.1:8000/get -i

curl -H "Host: test.a.rlp.com" http://127.0.0.1:8000/get -i

curl -H "Host: test.b.rlp.com" http://127.0.0.1:8000/get -i

curl -H "Host: test.c.rlp.com" -H "x-forwarded-for: 127.0.0.1" -H "My-Custom-Header-01: my-custom-header-value-01" -H "x-dyn-user-id: bob" http://127.0.0.1:8000/get -i

make local-cleanup

[gitguardian]

⚠️ GitGuardian has uncovered 1 secret following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

🔎 Detected hardcoded secret in your pull request

GitGuardian id	GitGuardian status	Secret	Commit	Filename
13357796	Triggered	Generic High Entropy Secret	8dd4c97	utils/deploy/authconfig.yaml	View secret

🛠 Guidelines to remediate hardcoded secrets

1. Understand the implications of revoking this secret by investigating where it is used in your code.
2. Replace and store your secret safely. Learn here the best practices.
3. Revoke and rotate this secret.
4. If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.

To avoid such incidents in the future consider

• following these best practices for managing and storing secrets including API keys and other credentials
• install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.

---

^{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.}

[adam-cattermole]

When this cluster is named authorino I am unable to reach it from within the shim so for now it is named authorino_wasm - todo: investigate why this is the case

[adam-cattermole]

I haven't had a chance to figure this one out yet, still somewhat curious but I don't think it's urgent

[eguzki]

Overall looks good.

• Documentation is needed
• I like the docker-compose environment, looks like more lightweight and quicker to work with. However, with authorino, due to it's complexity, and being a k8s controller, docker-compose is no longer an option. Should we keep both environments? any thoughts on this?

[eguzki]

this file is a template, which is rendered with the right wasm path. This adds some (minor) extra complexity.

Have you considered volume source being a secret which could be easier to manage and monitor?

[adam-cattermole]

My idea was to reduce the number of changes required to iterate as developing - so a simple rebuild using make build has generated a new file in the kind cluster (it still needs reloading so a make local-rollout is also needed).

That being said it's still pretty simple to re-create the secret each time we rebuild so I'm not tied to one approach or the other. If you prefer the secret I can look into it

[adam-cattermole]

@eguzki agreed, will look to add all the docs on using this.

I like the docker-compose environment, looks like more lightweight and quicker to work with. However, with authorino, due to it's complexity, and being a k8s controller, docker-compose is no longer an option. Should we keep both environments? any thoughts on this?

I was also unsure on this one - I agree docker-compose is a good lightweight alternative for limitador only, but then again two different dev environments might have differences which make it hard to spot issues. I think that whether we remove the docker-compose or not I'll leave it to a future PR outside of this one though.

[eguzki]

@adam-cattermole The PR includes some commits not related to the integration development environment. Not sure that is intended or not.

Regarding the integration development environment, I think it needs few more iterations, but we can polish it in following up PR's. LGTM.

[adam-cattermole]

@eguzki Oh you're right, it's diverged from base branch, let me rebase again

[didierofrivia]

🆒