Today I've experienced very unusual behavior of Google AppEngine's firewall.
I've an app running inside of GKE pod and another one is running inside of AppEngine.
I need my pod to be able to access AppEngine
If I do curl from a pod like this
curl ifconfig.co
I see
35...*
btw, if I'm trying to crul ipinfo.io/ip answer is 0.0.0.0.
Now, with I'm trying to permit those IP address in AppEngine's firewall , but nothing's happens. (10.0.0.0/8 network is also permitted, default rule set to prohibited).
After that I tried to permit all traffic to AppEngine and determine , which IP is visible for it.
And here's what I get:
protoPayload: {
#type: "type.googleapis.com/google.appengine.logging.v1.RequestLog"
appEngineRelease: "1.9.71"
appId: "redacted"
cost: 2.3245e-8
endTime: "2019-12-06T13:50:49.895089Z"
finished: true
first: true
host: "redacted.appspot.com"
httpVersion: "HTTP/1.1"
instanceId: "redacted-id"
instanceIndex: -1
ip: "0.0.0.0"
latency: "14.364944s"
IP is 0.0.0.0.
If I permit 0.0.0.0 in firewall AppEngine get's accessible for pod but not for other world.
Is that expected behavior?
When the firewall rule is set for 0.0.0.0 it only allows that IP, and 0.0.0.0/0 is the whole internet.
So If the firewall rule you set was only for 0.0.0.0 it is an expected behavior.
Related
I am building msa using eureka, zuul and with google appengine standard.
The problem is that zuul routing works normally in the local environment, but not in the GAE environment.
If I look at the Eureka page, I can check the registered services.
but The href link in the status column is "192.168.1.1:8080/info"
I know 192.168.1.1 is private ip address... can't access..
The methods i tried
#Eureka Standalone Server
eureka:
client:
registerWithEureka: false
fetchRegistry: false
serviceUrl:
defaultZone: https://my-eureka-server.appspot.com/eureka/
#Eureka Client
eureka:
instance:
prefer-ip-address: true
client:
serviceUrl:
defaultZone: https://my-eureka-server.appspot.com/eureka/
this result -> http://192.168.1.1:8080/info
#Eureka Client
eureka:
instance:
hostname: my-eureka-client.appspot.com
client:
serviceUrl:
defaultZone: https://my-eureka-server.appspot.com/eureka/
this result -> http://my-eureka-client.appspot.com:8080/info, also can't access
I want to http://my-eureka-client.appspot.com/info
what is hostname???
In local environment, If the euraka hostname is localhost or not specified,
href link is http://localhost:8080/info or http://MY-DESTOP-ID:8080/info
It can access.
Situation:
I work at big company and we have a k8s cluster.
We also have a database that is hosted somewhere else outside of the cluster.
The database IP-Adress and the Cluster have a bi-directional FW Clearance.
So applications that are hosted inside the cluster can connect to the database.
My machine does not have any clearance to the Database. I cannot test my app, write queries and so on. That slows me down and forces me to go to work, if any database-operations are required for it.
Question:
Since I can connect and deploy on the cluster. Could I deploy a NodePort/Service/etc to a service which forwards it directly to the database?
In this way it would "fool" the Database that the request comes from the cluster. But instead it comes from my machine at home.
Has anybody tried something like that?
Thanks in advance
you won't be able to set up a proxy that way. If you have an application that receives requests and forwards them to your database.
An easier solution would be to deploy your app to the cluster (if possible) or deploy a test pod to the cluster (using a base image like debian, busybox, or alpine linux; which ever image serves your needs). You can then connect to the pod (kubectl exec -it podname).
You could try to use NodePort service without selector and define your own endpoint pointing to database IP address.
For instance:
vagrant#k8sMaster:~$ nslookup google.fr
Name: google.fr
Address: 216.58.207.131
echo '
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
type: NodePort
ports:
- protocol: TCP
port: 443
targetPort: 443
' >> svc-no-sel.yaml
echo '
apiVersion: v1
kind: Endpoints
metadata:
name: my-service
subsets:
- addresses:
- ip: 216.58.207.131
ports:
- port: 443
' >> ep-no-sel.yaml
k apply -f svc-no-sel.yaml
k apply -f ep-no-sel.yaml
Where you replace google IP/Port by your database IP/Port.
Then in the given example you can target the service by doing
curl -k https://<node-ip>:<node-port>
Documentation on service without selector here: https://kubernetes.io/docs/concepts/services-networking/service/#services-without-selectors
I can not make the Apache Solr installation respond successfully.
I comment quickly, I have a Wordpress droplet in digital ocean, I installed Apache sorl and apparently it is running correctly.
$ service solr status
● solr.service - LSB: Controls Apache Solr as a Service
Loaded: loaded (/etc/init.d/solr; bad; vendor preset: enabled)
Active: active (exited) since Tue 2019-06-18 20:20:55 UTC; 1 day 9h ago
Docs: man:systemd-sysv-generator(8)
Process: 4342 ExecStop=/etc/init.d/solr stop (code=exited, status=0/SUCCESS)
Process: 4458 ExecStart=/etc/init.d/solr start (code=exited, status=0/SUCCESS)
Tasks: 0
Memory: 0B
CPU: 0
The ip xxx.xx.xxx.xxx is my droplet IP, and I only want from this IP queries can be made to apache sorl.
$ ufw status
WARN: / is group writable!
Status: active
To Action From
-- ------ ----
22 ALLOW Anywhere
443 ALLOW Anywhere
80 ALLOW Anywhere
Nginx HTTP ALLOW Anywhere
8983 ALLOW xxx.xx.xxx.xxx
22 (v6) ALLOW Anywhere (v6)
443 (v6) ALLOW Anywhere (v6)
80 (v6) ALLOW Anywhere (v6)
Nginx HTTP (v6) ALLOW Anywhere (v6)
If I filter the ips to see if as is configured
$ sudo netstat -lntp | grep 8983
tcp 0 0 127.0.0.1:8983 0.0.0.0:* LISTEN 4507/java
Ping from inside of my droplet server (ssh).
$ ping http://localhost:8983/solr
ping: unknown host http://localhost:8983/solr
How to get an answer from apache solr, what is happening?
First, what you're seeing is caused by Solr only listening to the loopback interface by default. This is to avoid people inadvertently exposing Solr directly to the internet (which it is not meant for). The netstat command shows this:
tcp 0 0 --> 127.0.0.1:8983 <--
To change what interface Solr listens to, you can add -Djetty.host=<ip> to the SOLR_OPTS used when starting Solr. How this is done depends on how you've installed Solr, but usually through solr.in.sh or something similar.
Second: Make sure your firewall is set to disallow connections by default, otherwise the single Allow for the port won't change anything. Test this from outside your host to make sure you're not exposing Solr to the whole internet.
Third: ping does not work like that. ping <ip> is how you'd use the ping utility, and this sends an ICMP packet to the ip (or host which is resolved to an ip) and waits for a response. It'll not work against a http URL, a given port or an endpoint path.
I'm trying to connect to google sql cloud instance from custom runtime environment in App Engine.
When I follow the doc to connect using unix domain socket, it works. The problem is when I try to connect using a TCP connect. It shows:
Warning: mysqli_connect(): (HY000/2002): Connection refused in
/var/www/html/index.php on line 3
Connect error: Connection refused
This is my app.yaml file:
runtime: custom
env: flex
beta_settings:
cloud_sql_instances: testing-mvalcam:europe-west1:testdb=tcp:3306
resources:
cpu: 1
memory_gb: 0.5
disk_size_gb: 10
The Dockerfile:
FROM php:7.0-apache
ENV PORT 8080
CMD sed -i "s/80/$PORT/g" /etc/apache2/sites-available/000-default.conf /etc/apache2/ports.conf && docker-php-entrypoint apache2-foreground
RUN docker-php-ext-install mysqli
RUN a2enmod rewrite
COPY ./src /var/www/html
EXPOSE $PORT
And index.php:
<?php
$link = mysqli_connect('127.0.0.1', 'root', 'root', 'test');
if (!$link){
die('Connect error: '. mysqli_connect_error());
}
echo 'successfully connected';
mysqli_close($link);
?>
What am I doing Wrong?
The ip address ‘172.17.0.1’ is related with the docker container where the webserver is running, you can get more context on that in this documentation.
The documentation page you’re using might be lacking on adjusting the use case if you’re deploying with a presence of a Dockerfile. In the following documentation you can read more information about App Engine flexible runtimes.
As demonstrated by the documentation you’re using (remember to click on the TCP CONNECTION tab on this page), on the section of the app.yaml related to Cloud SQL instances information about the TCP port in use by the database server is needed.
I'm running GAE dev server within a Vagrant guest precise64 box with the following network setup (in my Vagrantfile):
Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
config.vm.network :forwarded_port, guest: 8080, host: 9090
end
Which does its thing:
[default] Forwarding ports...
[default] -- 8080 => 9090 (adapter 1)
I start my App Engine server with:
goapp serve
or
dev_appserver.py myappfolder
This starts app engine dev server as expected:
INFO 2013-11-22 dispatcher.py] Starting module running at: http://localhost:8080
In all cases, I'm able to ssh in to the Vagrant guest and curl localhost:8080 successfully.
Unfortunately, from the host I'm unable to get a response from localhost:9090 when running GAE dev web server. Additionally, I've made sure that I don't have anything interfering with the port 9090 on the host machine. Also, I'm almost positive this isn't related to Vagrant as I spun up a quick node.js web server on 8080 and was able to reach it from the host. What am I missing?!!!
You must run the Google App Engine Go dev web server on 0.0.0.0 when leveraging Vagrant port forwarding. Like so:
goapp serve -host=0.0.0.0
See the answers here for more info on ensuring the guest web server is not bound to 127.0.0.1 which is loopback. Web servers that bind to 127.0.0.1 (like App Engine Go dev web server does) by default should be overridden to use 0.0.0.0.