So I'm hoping someone can give me some insight in my problem.
Been googling, reading blogs/articles, checking the documentation, but can't really figure it out...
So, if I want to deploy Openshift/OKD to a VPS, doesn't matter if it's the all-in-one deployment or not: how do I secure the web console?
I was expecting that it would be possible to e.g. execute an "oc cluster up" with public-master equal to my local-ip or public ip. Then, use iptables to block access to this port publicly and use ssh port forwarding (in putty) to access the webconsole. However, apparently accessing the web-console executes some form of forwarding, which basically makes ssh port forwarding for accessing it fail. I tried with ssh port forwarding by both setting the public master to my localhost ip and my public ip of the vps: same issue, ssh port forwarding doesn't work.
What I definitely do NOT want to do, is just expose the web-console to everyone with just a username and password combination.
So what options are there to actually secure the web console for openshift for public access over the internet?
There are a lot of articles to be found online on how to deploy it, but basically they all just seem to expose the web console publicly to everyone...
had the same problem, that is, ssh port forwarding didn't work due to web-console forwarding and redirects.
Solved it by forwarding to the same port, which seems to work:
ssh -L 8443:localhost:8443 -f -N user#host
Forwarding to different port didn't work:
ssh -L 1443:localhost:8443 -f -N user#host
Related
I've created an Oracle Cloud infrastructure compute instance running Ubuntu 20.04. I am trying to open port 19132.
As per another question I found
Opening port 80 on Oracle Cloud Infrastructure Compute node
I've created a public subnet which has an internet gateway and added ingress rules for port 19132 (in the security lists)
netstat looks good
netstat -tulpn
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
udp 0 0 0.0.0.0:19132 0.0.0.0:* 1007/./bedrock_serv
I installed ufw and added rules to allow 19132 but I still can't connect to it from the outside world. Can anyone point out where I am going wrong?
I got the same issue on the Oracle cloud.
Here is what works for me;
First, install firewalld
sudo apt install firewalld
Then open the port in public zone;
sudo firewall-cmd --zone=public --permanent --add-port=19132/tcp
Finally, reload firewalld
sudo firewall-cmd --reload
Looks like you need to have a Public IP configured on that VM for it to be reachable from the internet.
Please look at
https://docs.cloud.oracle.com/en-us/iaas/Content/Network/Tasks/managingpublicIPs.htm
For an instance to communicate directly with the internet, all of the following are required:
The instance must be in a public subnet.
The instance must have a public IP address.
The instance's VCN must have an internet gateway.
The public subnet must have route tables and security lists configured accordingly.
You haven't mentioned anything about the route table. If missing add to it a route with destination=0.0.0.0/0 and target=the Internet Gateway.
Two questions come to mind:
You have specified two rules, one for TCP and one for UDP.
Your netstat shows that something is listening for UDP traffic. Is
there also something listening on TCP or are you using UDP only for
the test?
Can you tell us anything about the traffic characteristics
on this port? I'm asking because if it is UDP traffic the only way
for connection tracking to work is to track the source/dest IP and
port. Since the port will not be present in fragments, the traffic
will be dropped. This could be happening on the ingress or egress
side. To verify, you could create test ingress/egress rules for all
UDP traffic to/from your test IP.
Since your ingress rules are stateful, the egress rules shouldn't matter but it wouldn't hurt to double check them. If none of these things work, you might try a tool like echoping to get more insight into whether or not the traffic is having trouble on the ingress or egress side.
Please check the order of your IPtables rules. Could you post the following command's output for Input chain.
sudo iptables -S INPUT
I have seen Iptables rules as the single prominent reason for these issues.
Regards
Muthu
I think you have to allow user or add user who can connect like this:
create user 'user'#'publicIP' identified by 'password';
grant all privileges on *.* to 'user'#'publicIP' with grant option;
flush privileges;
Here publicIP can be '0.0.0.0' or your system IP address.
Don't use '0.0.0.0' as it is open to all, I have faced various breaches on my GCP machine which leads to account block.
On OCP 4.3 the oc login command generated from the dashboard "Copy Login Command"
oc login --token=asdfghjk... --server=https://api.xxx.com:6443
fails with:
error: dial tcp: lookup api.xxx.com on 192.168.0.1:53: no such host - verify you have provided the correct host and port and that the server is currently running.
When I substitute the public ip of my cluster for the hostname it works.
oc login --token=asdfghjk... --server=https://1.2.3.4:6443
I can successfully ping api.xxx.com, the curl command generated by "Copy Login Command" resolves the hostname, and the curl url also works in chrome. I've tried adding the host and public ip to my /etc/hosts file but it still fails.
Is there some oc command configuration option I'm missing? Or perhaps a local proxy that I need to start? (Odd that the error msg says ...on 192.168.0.1:53...)
Versions:
$ oc version
Client Version: openshift-clients-4.3.0-201910250623-88-g6a937dfe
Server Version: 4.3.0
Kubernetes Version: v1.16.2
$
Update:
I've opened an oc issue for this:
https://github.com/openshift/oc/issues/315
This is not a problem with the oc client. It is working as expected.
The DNS server the machine you're running the oc command on does not know about the OpenShift DNS entries.
Judging by the IP 192.168.0.1 its your router.
If you deployed OpenShift in the cloud you need to make sure you're using a Public DNS zone so the DNS entries are resolvable from anywhere.
Alternately you could put those entries in the /etc/hosts file on your local linux machine (if its Windows the path is different) or you could put them in the DNS settings in your router.
I encounter the similar "No such host" problem run oc rsh command. After oc logout and oc login again, the problem is resolved.
Had same problem today on MacOS.
Ping worked to resolve the host BUT nslookup and dig both could NOT resolve the host, and the nameserver that dig and nslookup used was my default gateway address / port 53.
Fix:
Go to System Preferences > Network > Advanced > DNS tab. Add in name servers that resolve the hostname, which in my case are intranet nameservers (i'm VPN'ed). I also added in several public nameservers just in case.
Now Dig / nslookup resolve the host, and my oc login works
Conclusion?
I'm not sure this is an oc issue as much as it is a VPN configuration problem. Seems VPN did not add in intranet DNS properly. However I cannot explain why, before i added the nameservers, ping worked but dig/nslookup did not.
I have deployed the Spring boot app on the OCI compute and its comping up nicely. Compute is created with public ip and have the security list updated to allow connections from internet. But, I wasn't able to hit the end point from internet. For that reason, I thought of configuring the load balancer.
Created load balancer in a separate subnet(10.0.1.0/24), routing table and security list. Configured the LB's security list to send all protocol packets to compute's CIDR(10.0.0.0/24) and configured compute's security list to accept the packets from LB. I was expecting LB to make connection with back end. But, its not.
I am able to hit the LB from internet :-
Lb's routing table with all ips routed through internet gateway. There is no routing defined for compute's CIDR as its in the VCN.
LB has its own security list, which has allowed out going packets to compute and incoming from internet as below:
Compute's security list accepting packet's from LB:
Let me know, if I am missing something here.
My internet gateway :-
My backend set connection configuration from LB:
LB fails to make connection with backend, there seems to be no logging info available :
App is working fine , if I access from the compute node :
The LB has a health check that tests the connection to your service. If it fails, the LB will keep your backend out of rotation and give you the critical health like you're seeing.
You can get to it by looking at the backend set and clicking the Update Health Check button.
Edit:
Ultimately I figured it out, you should run the following commands on your backend:
sudo firewall-cmd --permanent --add-port=8080/tcp
sudo firewall-cmd --reload
Use the port that you configured your app to listen on.
I used httpd instead of spring, but I also did the following
sudo semanage fcontext -a -t httpd_sys_content_t "/var/www/html(/.*)?"
sudo restorecon -F -R -v /var/www/html
I'm not really too familiar with selinux but you may need to do something similar for your application.
Additionally, setting up a second host in the same subnet to login to and test connecting to the other host will help troubleshooting, since it will verify if your app is accessible at all outside the host that it's on. Once it is, the LB should come up fine.
TL;DR In my case it helped to switch the Security List rules from stateful to stateless on the 2 relevant subnets (where the loadbalancer was hosted and where the backends were located).
In our deployment I had a loadbalancer with public IP located on one subnet, while the backend to this loadbalancer was on another subnet. Both subnets had one ingress and one egress rule - to allow everything (i.e. 0.0.0.0/0 and all ports allowed). The backends were still not reachable from the loadbalancer and the healthchecks were failing.
Even despite the fact that in my case as per the documentation switching between stateful and stateless should not have an effect, it solved my issue.
I wanted to experiment with hosting a tiny murmur server, up to a few people.
Using a diy cartridge template, and a static build of murmur.x86, I've been able to start Murmur on the allowed OpenShift IP address.
However, how, if there's any way, would I be able to access the actual murmur server from a client, without requiring SSH > Port Forwarding from mine (and anyone else's who may want to access) local PC?
There is currently no way to expose ports other than 80/443/8000/8443 publicly on OpenShift Online. You are also able to make raw TCP connections to those ports, you can only use http/https/ws/wss. The only way to access the ports that murmur uses is over ssh port forwarding. If you would like to run a murmur server you would need to use a virtual machine that has it's own ip address and all ports exposed.
I want to try out some of the MySQL software, like Workbench, on the MySQL Db I develop on at work. After many failed attempts to make the connection, I finally asked one of the server admins if I was doing something wrong and was informed that the Db is behind firewall. So I can use phpMyAdmin, since it's installed server-side, but not Excel, Workbench, etc (from my machine).
So I would like to know if there is a fairly standard way to make a VPN-like connection to the server. Currently I use an SSH client to connect with no problem. But obviously that's not linking my local apps to the server. So can I make the connection in such a way that my whole system (so to speak) is considered signed on to the server? VPN is the closest analogy I can make, but that's not an option.
And....
Is that considered fairly "black hat" or is just something I don't know how to do but all the cool kids are doing it legitimately?
Thanks
This is simple using SSH tunneling. Simply do something akin to the following:
ssh -f username#your.remote.host -L 4040:your.remote.host:3306 -N
This does the following:
-f - forks SSH into background
username#your.remote.host - the user & host for SSH to connect to
-L 4040:your.remote.host:3306 - Listen for local connections on port 4040, and forward them via SSH to your.remote.host port 3306
-N - tells SSH not to issue a command on the remote host
You would then be able to connect to your mysql server (assuming the above ports are correct) using:
mysql --host=localhost --port=4040 --user=mysqluser -p
SSH tunnelling is excellent and can make life a lot easier.
The advantages are that it is all running over an encrypted port, 22, so the security is better and you can also compress the session, so over a slow network might see a bit of a performance improvement...
If you are using Windows, I would recommend puTTY which is available easily if you google it... Once connected, you can assign a local port which forwards to a port on the remote machine. In puTTY, this is in the Connection->SSH->Tunnels dialog.
I often use this for forwarding VNC - so if you have localport 5900 forwarding to the remote address 5900, you can connect to localhost:5900 as if you were connecting to the remote IP address.
It is also useful if there is a "hop" to a remote network - e.g. you aren't limited to forwarding to the ssh server you are connected to, you can also connect to other servers via the ssh server you are using.
Finally, I don't think that there is anything illegitimate about this option - you are using the ssh connection as intended and have been granted access to the server you are using. If anything, it is increased security...
Admins where I am have an Open-VPN that connect their personnal computer at home to servers at work, but it is used only for maintenance and 'emergency'.
I don't think it is good for security to have "holes" in the firewall, especially to a private place, where there is no firewall to protect your personnal computer.
These kind of practise is possible but has to be retricted to minimum