Open reskin89 opened 1 year ago
@reskin89 , this sounds an interesting use case. I am wondering if the event
API could serve this purpose.
For example, I can image that by integrating consul event
, consulwatch
, and some external message notification (like slack), a team can push an event to consul, which triggers a watcher script, followed by a slack message (written in the script) being sent to the team owning the service.
That's even further than I was thinking and sounds really cool!
@reskin89 : I have some follow-up questions on this. Let me know if you'd prefer to discuss over a call, it might be easier than a back-and-forth here. I could post a summary for others viewing this issue if they are interested.
I'm curious how intentions for your deployment are managed today. For example, as they stored "as code" somewhere, so they can be applied at any time to recreate that state? If so, how do you imagine this request notification interacting with the "intentions as code" setup?
Maybe the request notification doesn't have to interact with the "intentions as code" setup (meaning: no button in a Consul UI asking "do you want to grant this access request" and then it modifies the intention for you). It could instead be purely for notification, and then it's on recipient of the notification to make whatever changes they want the way they normally would.
Do you have a sense of where you might expect to be able to receive a notification? Maybe there would be some metadata you could attach to a service definition that tells Consul how to notify for intention requests about that service? I'm not sure. Let me know what you think!
great questions @jkirschner-hashicorp !
So I'm running an OSS cluster that's multitenant. I segment my clients with acl policies. The intention management is up to the team owning the service that's running to configure intentions.
My initial theory here would be to add something like a "notification push url" to consul, so that certain events can have a json blob with:
The other approach I envisioned was to add these "events" as an option in logging so we can parse it out ourselves.
I know consul has an events type of API, which, if this was added there, anyone could write a polling application to pull events and do with them whatever they'd wish to do.
I personally think the simpler approach for consul is better, instead of baking in an entire modular notification suite, just provide users/admins with the information so they can create the tool.
That would most likely breed a nice open source ecosystem of different "Consul Events Connectors" that utilize it.
Feature Description
In the situation of multi tenancy, it would be nice if an application owner could "request" an intention be added to allow their service to speak to another, at which point some type of marking would be denoted on the requested service to see that they have a request to allow/deny a service.
Use Case(s)
Service Mesh Use Case: Administrating a consul cluster that allows multiple teams/applications on it, to allow those teams to more easily communicate and add/remove intentions between each other.