-
-
Notifications
You must be signed in to change notification settings - Fork 13
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
RFC: ACL #5
Comments
Sorry for my delay. I was testing the another PR. First of all, I like the idea of implement more functionality to the service, however we have to keep in mind that we cannot make it so complex that we'll lose the proposal to be an Anyway, the idea still can be worked, and I have some questions. Example 1:
Example 2
The only issue is that it is not clear the exact action. So, my suggestion is follow anything in this line: example 1:
It would render the following config block:
example 2
It would render to:
|
Any comment? |
@byjg sorry, bit swamped. Saw this in my inbox and been meaning to do something. So basically, you would do "acl-reject" and "acl-accept"? And then render based on that? I think I like that idea! :) |
I have another proposal, so here it comes... If you have time, I'd like your input. I'll build everything, etc..
Proposal
I want a basic service firewall so I can stop dealing with iptables/firewalld on the docker host system.
So, my "proposal" is: I wanted a way to set ACL on frontends, via service/container labels.
Example 1
A simple ACL to ensure a service can be accessed only from
1.1.1.1
:It would render the following config block:
Do you think this is over-complicating it?
Example 2
Here is another example — I have an internal API server, I want to ensure that requests originate from
10.0.1.0/24
or10.0.2.2
and each request must start with/api/v2
:It would render to:
Different
acl-name
s would render anotherhttp-request deny if
statement.Thoughts?
The text was updated successfully, but these errors were encountered: