-
Notifications
You must be signed in to change notification settings - Fork 345
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create a Istio trait #209
Projects
Comments
@nicolaferraro is this still needed ? |
Yes, but we maybe want to go in another direction. Look at: istio/istio#9304 (comment) The istio trait may add the |
nicolaferraro
added a commit
to nicolaferraro/camel-k
that referenced
this issue
Dec 6, 2018
nicolaferraro
added a commit
to nicolaferraro/camel-k
that referenced
this issue
Dec 6, 2018
nicolaferraro
added a commit
to nicolaferraro/camel-k
that referenced
this issue
Dec 6, 2018
nicolaferraro
added a commit
to nicolaferraro/camel-k
that referenced
this issue
Dec 6, 2018
ipolyzos
pushed a commit
to ipolyzos/camel-k
that referenced
this issue
Jul 31, 2019
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
While developing the Knative integration I've noticed that outgoing connections are not allowed when the pod is embedded into the Istio mesh.
If you want to contact e.g. slack you should add a
EgressRule
like:It would be great if we can add a
Istio
trait that can add those rules automatically (as child resource of theIntegration
).Users may be able to run a integration like:
That will end up in the
Integration
resource, in theistio
trait and then materialized by the operator.The next big thing would be to add such egress rules automatically from the code... But we don't have such metadata in Camel. Some endpoints, instead, are self describing, such as
.to("http://..")
.Does anyone know if there's a "wildcard" authorization for Istio egresses or external services should all be declared?
The text was updated successfully, but these errors were encountered: