I get that it wont be possible to bind the service and therefore not use the VCAP_SERVICES, and credentials would need to be managed in another way.
Since the communication would go via the internet, I guess the question is really:
Does the SSO service have an API that can be reached from outside of Bluemix?
Yes the SSO service can be reached from outside Bluemix and therefore also from apps deployed on UK.
However, to retrieve the credentials you need to create an SSO service on US and then bind an app to it and inspect the VCAP_SERVICES. This is due to how Cloud Foundry works. Read more here
Related
I am new to Cloud Foundry.
Is there any way that only specific users can view and update an app deployed in Cloud Foundry?
1.I deployed an app in Cloud Foundry using “cf push”command.
2.After entering “cf push “command I’ve got an message below.
Using manifest file /home/stevemar/node-hello-world/manifest.yml
enter Creating app node-hello-world-example...
name: node-hello-world-example
requested state: started
routes: {route-information}
last uploaded: Mon 14 Sep 13:46:54 UTC 2020
stack: cflinuxfs3
buildpacks: sdk-for-nodejs
type: web
instances: 1/1
memory usage: 256M
3.Using the {route-information} above,I can see the app deployed via browser entering below URL.
https://{route-information}
By this way ,anyone can see app from browser, but I don’t want that to be seen by everyone and limit access to specific user.
I heard that this global IP will be allocated to {route-information} by default.
Is there any way to limit access to only between specific users?
(For example,is there any function like “private registry” at Kubernetes in Cloud Foundry which is not open to public)
Since I am using Cloud Foundry in IBM Cloud it would be better if there is solution using IBM Cloud.
I’ve already granted cloud foundry role to the other user.
Thank you.
The CloudFoundry platform itself does not provide any access controls for applications. If you assign a public route to your application, where the DNS is publicly resolvable and the foundation is on the public Internet, like IBM Bluemix, then anyone can access your app.
There's a number of things you can do to limit access, but they do require some work on your part.
Use a private DNS. You can add any domain you want to Cloud Foundry, even ones that don't resolve. That means you could add my-cool-domain.local which does not resolve anywhere. You could then add a record to /etc/hosts for this domain or perhaps run DNS on your local network to resolve this DNS domain and direct traffic to the CloudFoundry.
With this setup, most people cannot access your application because the DNS domain for the route to your application does not resolve anywhere. It's important to understand that this isn't really security, but obscurity. It would stop most traffic from making it to your app, but if someone knew the domain, they could add their own /etc/hosts header or send fake Host headers to access your application.
This type of setup can work well if you have light security requirements like you just want to hide something while you work on it, or it can work well paired with other options below.
You can set up access controls in your application. Many application servers & frameworks can do things like restrict access by IP address or require user access (Basic auth is easy and it is OK, if you're only allowing HTTPS traffic to your app which you should always do anyway).
You can use OAuth2 to secure apps too. Again, many app servers & frameworks have support for this and make it relatively simple to secure your apps. If you don't have a corporate OAuth2 solution, there are public providers you can use. Exactly how you do OAuth2 in your app is beyond the scope of this question, but there's plenty of material out there on how to do this. Google information for your application language/framework of choice.
You could set up an access Gateway. This would be an application that's job is to proxy traffic to other applications on the foundation. The Gateway could be something like Nginx, Apache HTTPD, or Spring Cloud Gateway. The idea is that the gateway would be publicly accessible, and would almost certainly apply access controls/restrictions (see #2, many of these proxies have access control options that only take a few lines of config). Your actual applications would not be deployed publicly though. When you deploy your actual applications, they would only be on the internal Cloud Foundry domain.
CloudFoundry has local domains, often apps.internal (run cf domains to see if that shows up), which you can use to easily route traffic across the internal container-to-container network. Using this domain and the C2C network, you can have apps deployed to CF that are not accessible to the public Internet, except through your Gateway.
Again, how you configure this exactly is outside the scope of this question, but check out the docs I linked to for info on using the C2C network & internal routes. Then check out your proxy server of choice's documentation.
Most of the document I found about GCP, the REST API needs a user interaction for authentication. Is there a possible way to access the GCP resource without an interaction from user.?
eg: I would like to implement a cron job in my local workstation to launch a GCP machine.
Yes, it's possible, this is that service accounts are for:
A service account is a Google account that represents an
application, as opposed to representing an end user.
Important: For almost all cases, whether you are developing locally or in a production application, you should use service
accounts, rather than user accounts or API keys. You can use a service
account by providing its private key to your application, or by using
the built-in service accounts available when running on Google Cloud
Functions, Google App Engine, Google Compute Engine, or Google
Kubernetes Engine.
All GCP APIs support service accounts. For most server applications
that need to communicate with GCP APIs, we recommend using service
accounts, as they are the most widely-supported and flexible way to
authenticate.
For more information, see getting started with authentication.
You'd have to create a service account representing your application (executed as the cron job) and in your application you'd authenticate the REST API calls using that service account's credentials.
I want to expose a REST-ful service as an API to the outside world on Bluemix Public. Therefore I have a liberty app, containing a REST service implemented in JAX-RS.
Additionally I leverage the "API Management Service" to secure that app, via Plans, Authentication etc. So thanks to the API Management Gateway I have a secure proxy to my service exposed.
Yet, the app that provides my service remains accessible to the outside via the Bluemix route. So, it can be called without any credentials or whatsoever.
Is there a way, to only have my API Management gateway access the service implementation app?
One approach would be to delete the route of the service implementing app, but how would you then bind the API Management to the service?
Happy to hear your thoughts or alternative solutions.
If your API is running on Bluemix Public as a Cloud Foundry application, there is currently not a way to create a route such that it is only accessible by the API management service, but not the the outside world. You should implement security within your jax-rs application (easy to with web.xml security-constraint) and add those credentials to APIm service if you still want to use APIm to get monitoring, throttling, discovery, etc.
Another option would be to deploy the application in a VM and then use Secure Gateway to connect to it:
https://github.com/IBM-Bluemix/onprem-integration-demo
I saw the following document.
https://www.ng.bluemix.net/docs/services/SecureGateway/index.html#sg_overview
In the summary near the end, it says "Provision the service and bind it to your app". But do I really need to bind the secure gateway service to my app? I could access the secure gateway's destination without binding the service.
I found the same when testing with DB2 and could access the gateway without binding, too.
Binding a service to an app is for the metadata and simplifies administration and deployment. If you delete an app, the related services will also be removed. If you try to delete a service bound to an app, there should be a warning. So what is in the documentation makes sense (at least this time...).
You are correct. Since the Secure Gateway service does not actually use VCAP services there are no advantages to binding your application to the service instance.
I'm just confused on how CloudFoundry exactly works.
So if I create a service, will it be hosted on their cloud and I can expect it to run indefinitely?
Yes, CloudFoundry will host your service and it will run as long as they are up, but to access it you must bind the service to an app.
The concept of service in Cloud Foundry is quite open, it can refer to an app running in CF or outside, e.g. somewhere on the local network or on AWS or anywhere else.
I recently wrote a blog entry about how you can turn an existing app into a CF service, you might find it useful.