You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cloudstack.apache.org by "btzq (via GitHub)" <gi...@apache.org> on 2024/04/01 15:57:49 UTC
[I] Support ACL on Public IP [cloudstack]
btzq opened a new issue, #8863:
URL: https://github.com/apache/cloudstack/issues/8863
<!--
Verify first that your issue/request is not already reported on GitHub.
Also test if the latest release and main branch are affected too.
Always add information AFTER of these HTML comments, but no need to delete the comments.
-->
##### ISSUE TYPE
<!-- Pick one below and delete the rest -->
* Improvement Request
##### COMPONENT NAME
<!--
Categorize the issue, e.g. API, VR, VPN, UI, etc.
-->
~~~
Improvement Request (UI, Functionality)
~~~
##### CLOUDSTACK VERSION
<!--
New line separated list of affected versions, commit ID for issues on main branch.
-->
~~~
4.19
~~~
##### CONFIGURATION
<!--
Information about the configuration if relevant, e.g. basic network, advanced networking, etc. N/A otherwise
-->
N/A
##### OS / ENVIRONMENT
<!--
Information about the environment if relevant, N/A otherwise
-->
N/A
##### SUMMARY
<!-- Explain the problem/feature briefly -->
Note: This ticket is broken down as requested from the origianl post, https://github.com/apache/cloudstack/issues/8841
**Support ACL on Public IP**
- According to Terraform docs, it seems that this is possible: https://registry.terraform.io/providers/cloudstack/cloudstack/latest/docs/resources/firewall
- However, i cant seem to find this in the GUI. So in case this is not available in the GUI, would like to request to make this available.
##### STEPS TO REPRODUCE
<!--
For bugs, show exactly how to reproduce the problem, using a minimal test-case. Use Screenshots if accurate.
For new features, show how the feature would be used.
-->
N/A
<!-- Paste example playbooks or commands between quotes below -->
~~~
N/A
~~~
<!-- You can also paste gist.github.com links for larger files -->
##### EXPECTED RESULTS
<!-- What did you expect to happen when running the steps above? -->
~~~
To be able to manage ACL Rules more easily for large scale projects
~~~
##### ACTUAL RESULTS
<!-- What actually happened? -->
<!-- Paste verbatim command output between quotes below -->
~~~
Challenging to use ACL rules for large scale projects.
~~~
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@cloudstack.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] Support firewall rules on Public IP in VPC [cloudstack]
Posted by "weizhouapache (via GitHub)" <gi...@apache.org>.
weizhouapache closed issue #8863: Support firewall rules on Public IP in VPC
URL: https://github.com/apache/cloudstack/issues/8863
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@cloudstack.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] Support firewall rules on Public IP in VPC [cloudstack]
Posted by "CodeBleu (via GitHub)" <gi...@apache.org>.
CodeBleu commented on issue #8863:
URL: https://github.com/apache/cloudstack/issues/8863#issuecomment-2950929370
Not sure if this is the correct place to ask or not, but with my current issue of locking down a Load Balancer in a VPC network. I've ran into issues where the VPC network ACL doesn't work for a Load Balancer and I'm not sure what the expected behavior should be?
If I create or [update source CIDR](https://github.com/apache/cloudstack/pull/10968) of the LB rule it will restrict based on the source CIDR, however nothing in the VPC ACL will actually restrict access to my LB
This is completely different behavior when it's a non-VPC. A non-VPC network will actually use the firewall correctly to restrict the access.
I believe the Load Balancer source CIDR itself should be the first line of defense and if it is set to (0.0.0.0/0 - default), then the firewall ( non-vpc ) or ACL ( VPC ) should be the next line of defense.
Any help in the direction this should go would be much appreciated.
I'm needing this to work for the cloudstack-kubernetes-provider so it can set the LB source CIDR on creation, as the creation of the ACL's are not working and just leaves things wide open based on the default source CIDR of the LB being open by default. @Pearl1594 It appears you last worked on [this](https://github.com/apache/cloudstack-kubernetes-provider/pull/69), and hopefully you can be of some help here.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@cloudstack.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] Support firewall rules on Public IP in VPC [cloudstack]
Posted by "weizhouapache (via GitHub)" <gi...@apache.org>.
weizhouapache commented on issue #8863:
URL: https://github.com/apache/cloudstack/issues/8863#issuecomment-2952103869
> Not sure if this is the correct place to ask or not, but with my current issue of locking down a Load Balancer in a VPC network. I've ran into issues where the VPC network ACL doesn't work for a Load Balancer and I'm not sure what the expected behavior should be?
>
> If I create or [update source CIDR](https://github.com/apache/cloudstack/pull/10968) of the LB rule it will restrict based on the source CIDR, however nothing in the VPC ACL will actually restrict access to my LB
>
> This is completely different behavior when it's a non-VPC. A non-VPC network will actually use the firewall correctly to restrict the access.
@CodeBleu
you are right.
It is a known issue that network acl does not apply on LB in VPC
https://github.com/apache/cloudstack/discussions/10507
>
> I believe the Load Balancer source CIDR itself should be the first line of defense and if it is set to (0.0.0.0/0 - default), then the firewall ( non-vpc ) or ACL ( VPC ) should be the next line of defense.
>
unfortunately, source CIDRs and network ACLs are configured inside VR differently.
there is not iptables rules for the source CIDRs of LB, there are no haproxy configuration for network ACL either
you can refer to https://github.com/apache/cloudstack/pull/6460
> Any help in the direction this should go would be much appreciated.
>
> I'm needing this to work for the cloudstack-kubernetes-provider so it can set the LB source CIDR on creation, as the creation of the ACL's are not working and just leaves things wide open based on the default source CIDR of the LB being open by default. [@Pearl1594](https://github.com/Pearl1594) It appears you last worked on [this](https://github.com/apache/cloudstack-kubernetes-provider/pull/69), and hopefully you can be of some help here.
I'd like to see firewall rules support on Public IPs in VPC, similar to Public IPs in isolated networks.
however, for now you have to configure source CIDR for the LB
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@cloudstack.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] Support ACL on Public IP [cloudstack]
Posted by "DaanHoogland (via GitHub)" <gi...@apache.org>.
DaanHoogland commented on issue #8863:
URL: https://github.com/apache/cloudstack/issues/8863#issuecomment-2049281014
@btzq , if we implement #8864 , the firewall functionality will be supported by virtue of the private IPs. The user facing functionality will be somewhat different but the security features will be the same. A user wanting to set access lists into a VPC will have to know about its topology anyway. What do you think?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@cloudstack.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] Support ACL on Public IP [cloudstack]
Posted by "btzq (via GitHub)" <gi...@apache.org>.
btzq commented on issue #8863:
URL: https://github.com/apache/cloudstack/issues/8863#issuecomment-2050840516
@DaanHoogland when you mean topopology, do you mean that the users will need to know the existance of a the Virtual Router?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@cloudstack.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] Support ACL on Public IP [cloudstack]
Posted by "DaanHoogland (via GitHub)" <gi...@apache.org>.
DaanHoogland commented on issue #8863:
URL: https://github.com/apache/cloudstack/issues/8863#issuecomment-2051236639
> @DaanHoogland when you mean topopology, do you mean that the users will need to know the existance of a the Virtual Router?
yes, but mostly the mapping of private IPs to static NAT Ips and individual services mapped from other IPs to the backends.
bad example:
public 10.10.10.10 - source NAT
public 10.10.10.11 - static NAT to private 10.11.12.10
public 10.10.10.12 - port 80 loadbalanced over 10.11.13.10 and 10.11.13.11
etc.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@cloudstack.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] Support ACL on Public IP [cloudstack]
Posted by "btzq (via GitHub)" <gi...@apache.org>.
btzq commented on issue #8863:
URL: https://github.com/apache/cloudstack/issues/8863#issuecomment-2051271115
Hmm this is my opinion but i think part of the beauty of having cloud is that the customer does not need to know the topology of the underlying cloud service/infra. If the customer needs to learnt he existance of a router, it might complicate things for them and deter them from using the service.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@cloudstack.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org