How can I configure kube-proxy to connect via https to apiserver? - kubernetes

Reading the documentation from http://kubernetes.io/docs/admin/kube-proxy/ it doesn't look like I can connect to the apiserver via https.
The same goes for scheduler and controller-manager, but those two maybe are supposed to run on the same machine as the apiserver and can connect via localhost.
But what about the proxy? This is supposed to connect remotely to the apiserver. Is it possible to configure authentication and/or authorization from the proxy to the apiserver?

This is embarrassing. Looks like all daemons support a "--kubeconfig" flag that gives access to public and private key for authorization.

Related

How to setup k8s istio aspnet identity server for internal requests

We have a cluster that runs a number of dotnet apps, one of which runs the identity server. All the other apps need to authenticate with the identity server. If the identity server was external this wouldn't be an issue as it would have an HTTPS endpoint, but internally they are all running HTTP.
With istio adding MTLS security to all the comms, do all the apps just get set with RequireHttpsMetadata = false?
Is this the correct way to setup the network with internal requests being sent as http://auth-server.default.svc.cluster.local/...?
or should they be sent as https://auth-server.default.svc.cluster.local/..., if so how?

How To Configure PrestoDB internal communication in Kubernetes

I'm testing prestoDB with kubernetes, and I want to configure user and password auth, but it is necessary to have https configured.
Could you help me how to do that on kubernetes?
Im following this page:
https://prestodb.io/docs/current/security/internal-communication.html
But I didnt understand which domain I should issue a certificate.
Today Im using kubernetes service name resolution like a discovery uri
discovery.uri=http://prestodb-coordinator-service:8080

GKE private cluster and cloud sql proxy connection

I have 2 GKE cluster both private and public and using cloudproxy as sidecar container for gke app to access cloudsql instance.
public cluster setup for development/testing
Cloud SQL is enabled with both private and public IP.
GKE app is using cloudproxy with default option of ip types (public,private) as below
Cloud SQL doesn't have any authorized network.
In this case, my app is able to connect CloudSQL and works smoothly. As far as I understand, here connection to cloudsql should be happening with private becuase there is no authorised network configured.
private cluster setup for production
Cloud SQL is enabled with both private and public IP.
GKE app is using cloudproxy with default option of ip types (public,private)
cloudsql-proxy setting in deployment file
- name: cloudsql-proxy
image: gcr.io/cloudsql-docker/gce-proxy:1.11
command: ["/cloud_sql_proxy"]
args: ["-instances=$(REAL_DB_HOST)=tcp:$(REAL_DB_PORT)","-credential_file=/secrets/cloudsql/credentials.json"]
case 1
Cloud SQL doesn't have any authorized network.
Result: Application is not able to connect with Cloud SQL
case 2
Cloud SQL have private GKE NAT gateway as authorized network
Result: Application is not able to connect with Cloud SQL
May be removing cloudproxy from application will work (I am yet to test) but it discourages the usage of proxy during dev env as it will need changes in deployment file during production deployment.
I am not able to understand what is causing the connection failure with cloudproxy in gke private cluster. Should we not use cloudproxy in private cluster?
Update
The reason due to which cloud proxy not able to connect cloud sql was disabled Cloud SQL Admin API. I have updated my answer in answer section.
It looks like the question here is "Should we use the Cloud SQL proxy in a private cluster?" and that answer is "it depends". It's not required to connect, but it allows for more security because you can restrict unnecessary access to your Cloud SQL server.
The Cloud SQL proxy doesn't provide connectivity for you application - it only provides authentication. It has to be able to connect via the existing path, but then uses the Service Account's IAM roles to authenticate the connection. This also means that it doesn't have to come from a whitelisted network because it's been authenticated by a different means.
If you want to use the proxy to connect via Private IP (instead of defaulting to public), use the -ip_address_types=PRIVATE - this will tell the proxy to connect with the instance's Private IP instead. (Please note that if the proxy lacks a network path (eg, isn't on the VPC) that proxy will still be unable to connect.)
#kurtisvg has provided an informative answer to it.
However the real issue was SQL Admin API and enabling it fixed the issue. After looking into the logs I found below entry.
Error 403: Access Not Configured. Cloud SQL Admin API has not been used in project XXXXXX before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/sqladmin.googleapis.com/overview?
The issue for me was enabling Private cluster in GKE cluster :(
Because of private GKE cluster it wasn't having access to external IP addresses and fix was to create a NAT gateway with cloud router as per https://cloud.google.com/nat/docs/gke-example.
Hint if it's the issue is you won't be able to ping to google.com etc from the container after logging into it.

Enabling remote access to Keycloak

I'm using the Keycloak authorization server in order to manage my application permissions. However, I've found out the standalone server can be accessed locally only.
http://localhost:8080/auth works, but not it does http://myhostname:8080/auth. This issue doesn't permit accessing the server from the internal network.
The standalone Keycloak server runs on the top of a JBoss Wildfly instance and this server doesn't allow accessing it externally by default, for security reasons (it should be only for the administration console, but seems to affect every url in case of Keycloak). It has to be booted with the -b=0.0.0.0 option to enable it.
However, if your Wildfly is running on a remote machine and you try to
access your administrative page through the network by it’s IP address
or hostname, let’s say, at http://54.94.240.170:8080/, you will
probably see a graceful This webpage is not available error, in
another words, Wildfly said “No, thanks, I’m not allowing requests
from another guys than the ones at my local machine”.
See also:
Enable Wildfly remote access
Wildfly remotely access administration console doesnt work
you can start keycloak server with this command
standalone.bat -b 0.0.0.0
For anyone who happens by here now, I found this in the documentation for Keycloak 8:
Users can interact with Keycloak without SSL so long as they stick to
private IP addresses like localhost, 127.0.0.1, 10.0.x.x, 192.168.x.x,
and 172.16.x.x. If you try to access Keycloak without SSL from a
non-private IP address you will get an error.
This is how you can disable it from the admin console, just click on your realm, and make the mentioned option.
Note: Don't forget the following
standalone.bat -b 0.0.0.0

How to disable SSL in JAVA_OPTS in eclipse?

I am running Kubernetes API to access a kubernetes cluster. The connection fails with teh following error
javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
The kubernetes endpoint is http and not https. How do I make sure that this is configured in the JAVA_OPTS for eclipse>?
It sounds like you tried to access the wrong port.
By default, a secure port is opened on 6443. You should be able to make an SSL connection to that port:
https://github.com/kubernetes/kubernetes/blob/54706661ad72d62ea0b494112a74e0467093c9f4/cmd/kube-apiserver/app/server.go#L128
For up-to-date information about how to access the API, please take a look at the documentation:
http://kubernetes.io/v1.1/docs/user-guide/accessing-the-cluster.html
http://kubernetes.io/v1.1/docs/admin/accessing-the-api.html
If more information would be useful there, please file an issue requesting the specific information you would expect to see in the documentation.
https://github.com/kubernetes/kubernetes/issues/new