We have setup the snowflake privatelink and its working well from AWS side.
As per my understanding to make it work from on prem, on prem DNS records creation needs to be taken into consideration for *.privatelink.snowflakecomputing.com and as per the company DNS team this is not possible and it does not work as what is expected in case of AWS route53 private DNS scope.
I could not find any useful docs in the snowflake side or any other public domain about the on premise configuration.
I need to connect to the privatelink url or any URL from the on prem server and browser which will take me through the VPC endpoints and land me in snowflake private link console. I tried to create Network load balancer mapping towards the Private IP addresses of the snowflake related VPC endpoints , but it does not work , throws me 403 access denied .
#deb-pal regarding the point "DNS team told its not a good practice to recreate the the total hosted zone records in their private DNS," your DNS team is correct that this has not been a traditional practice. However, this sort of DNS override to support private communications with SaaS and cloud is a growing practice.
Snowflake's version of this is a little more guarded than some. We do not ask you to host anything in the form <label>.snowflakecomputing.com. That would have you potentially overriding records where we are clearly authoritative. Instead we ask you to host things in the form <label>.privatelink.snowflakecomputing.com. Snowflake will never host anything in that form.
The 403 Forbidden error occurs when you try to access the Snowflake privatelink endpoint via the internet. This means that your network isn't set up to route traffic to that endpoint via your AWS VPC. You will need to ensure:
You have connectivity between your local machine and the AWS VPC. You should be able to ping an ec2 machine with a private IP address from your machine.
The on-premises DNS needs to be set up to point the privatelink.snowflakecomputing.com at the AWS endpoint. If your on-premises DNS directs machines to the public IP address, it won't work (as this will be routed through public internet).
We have seen this issue with lots of Snowflake Customers . Their private link works well from AWS Route 53 side but fails to reach the private link endpoint from on-prem.
It seems your local DNS is not able to reach Route 53 CNAME.
You will have to configure DNS forwarding to make sure it reaches Route 53 hosted zone CNAME.
Related
The problem is simple: I have an OVH cloud database which I need to access from my Kubernetes cluster.
The cloud database has to whitelist authorized IPs. What I currently do is add each node IP upon creation. This can become tedious to maintain and also poses a problem with auto-scaling, since the created node will not have access the the database until the IP is manually whitelisted.
The official documentation and forum do not indicate how to proceed. It there any way to whitelist the whole cluster?
I have my snowflake warehouse hosted on an address that looks like this :
*********.snowflakecomputing.com/console (not sure where it is hosted - maybe within the Snowflake cloud). However, I do not have it configured to go through a VPN connection. Is there a way to require that console access is only through VPN?
I think you are asking about Network Policies.
Nit: I am not sure "insecure" is the right word to use. All data is transferred over HTTPS and is therefore encrypted. Using SAML you can use your own authentication provider and use MFA. Thus you can easily match the highest standards of security in the industry.
Yes, you can restrict access to your snowflake account using an account-level network policy.
You can define VPN IP(s) in the allowed IP list in the account level network policy and activate the policy.
After account level activation, everyone is required to connect the VPN before accessing the snowflake account.
Details: https://docs.snowflake.com/en/user-guide/network-policies.html#managing-account-level-network-policies
The scenario is this: Our snowflake will only be accessible by whitelisted IP addresses. If we plan to use AWS Glue what IP address can we use so that it will allow us to connect to snowflake? I need a way to identify that this AWS Glue job with IP address (endpoint) so that it can be identified in Snowflake. I want to use an AWS Glue because it is a serverless orchestration tool.
Thanks,
D.
AWS has specified the ip-ranges of several services and regions, but Glue is currently not listed.
You can achieve the required behavior with the following workaround:
Create a VPC with private and public subnet. Public subnet's route table will have the Internet Gateway, while private subnet's route table will have the NAT Gateway configured. Assign an Elastic IP address to your NAT Gateway.
Create a Glue Connection. You may enter any arbitrary JDBC string and password, yet you will assign the VPC and private subnet you just created. Assign the security group with all the inbound and outbound traffic open.
Attach this Glue Connection to your Glue Job, and from now on all the Glue Job traffic will pass through the NAT Gateway. The NAT Gateway's IP address must be whitelisted in snowflake.
More details about Glue Connection properties. Please consider that there's an extra hop of NAT Gateway that may cause minor delays.
To add onto #amsh's answer, the the NAT gateway should be created in the Public subnet but assigned in the route table of private subnet.
I’m looking at getting some servers migrated to azure and I’m stuck at the first hurdle, whether to set up Iaas servers as domain controllers and use Azure AD connect and enable pass thru authentication or to set up Azure AD Domain services and create a one way trust back to on premise and set it up as a resource domain .
The environment at the moment has a tiered architecture, with all key resources sitting in a tier 0 network on premise.
I think what I’d like to know is what does AD use to send the traffic on a trust relationship, I think AD connect uses port 443 and are there any benefits for using AADDS rather than Iaas VMS with ad connect?
Thanks in advance and hope that makes sense.
To answer your first question, network connectivity / traffic, here is the traffic map that is necessary for active directory services forest trust, https://support.microsoft.com/en-ca/help/179442/how-to-configure-a-firewall-for-domains-and-trusts
the RPC requires a lot of ports, and you cannot restrict it to specific ports.
As for your second question, using AAD DS the benefits is mainly that it's a managed service, you don't have to patch or manage any of domain controller infrastructure like you would a DC VM. you also don't need to manage the aadconnect configuration. But in return, with AADDS, you give up a bit of flexibility. Such as, you are not a domain/forest/enterprise admin. as this is all managed by Microsoft. the other thing you give up with aadds is schema extensions.
here is a doc on comparing between aadds and adds. https://learn.microsoft.com/en-us/azure/active-directory-domain-services/compare-identity-solutions#azure-ad-ds-and-self-managed-ad-ds
Hopefully this helps you on your journey to decide which architecture suits you better.
I am trying to provision users from On Premise AD to Azure AD. The firewall within my organization blocks the provisioning process. I referred the following link - https://learn.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-ports and referred the table 1, table 2, table 6a and 6b.
What this line states - For a list of URLs and IP addresses you need to open in your firewall, see Office 365 URLs and IP address ranges - https://support.office.com/en-us/article/office-365-urls-and-ip-address-ranges-8548a211-3fe7-47cb-abb1-355ea5aa88a2?ui=en-US&rs=en-US&ad=US#bkmk_portal_ip
In this URL, is it enough to raise firewall for the URLs under - Portal and shared FQDNs, Authentication and identity FQDNs.
Also there is one more link that displays Azure data center Ip ranges - https://www.microsoft.com/en-us/download/details.aspx?id=41653
What are these IPs mentioned in Azure data center. Should I need to raise for these as well?
I am really confused. Please any one help me ?
is it enough to raise firewall for the URLs under - Portal and shared
FQDNs, Authentication and identity FQDNs.
You are correct. That's all you need for AAD Connect to work.
You don't need the specific IP ranges. They are for the FQDNs listed under the page.