we deploy ceph S3 object storage and want secure RGW. Is there any solution or any user
experience about it?
Is it common to use WAF ?
Anyone using Ceph Object Storage will require a access_key and secret_key to interact with the service. This provides one level of security.
Firewalls on the server level (e.g. iptables) and firewalls on the network devices to only permit access from specific sources (unless you need RGW open to the world) could provide another.
Perhaps DDoS mitigation using something like Cloudbric, Akamai, or Cloudflare? Or even simply Fail2Ban banning IPs after a certain of number of incorrect credentials?
You haven't provided many details about your deployment and use-case, so it's hard to advise.
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.
I am trying to implement Grafana Auth Proxy as documented at
https://grafana.com/docs/grafana/latest/auth/auth-proxy/
https://community.grafana.com/t/django-auth-valid-session-on-grafana-behind-nginx/2793/6
Based on how it works, it seems X-WEBAUTH-USER is set in plain text. So any one who can spoof it, can get logged in.
Grafana does have a IP Whitelist, BUT I dont think its practice to maintain IP Addresses of Docker Containers (Django and Grafana are running in separate docker containers).
Questions:
Is there a better implementation to achieve some thing more secured?
Can whitelist have a easier value?
That is design. AuthProxy offloads the authentication to your own legacy "auth" server. Of course you will need to secure connection between auth server and Grafana, so no one will be able to spoof it. For example you may create dedicated docker network (mutual TLS connection, VPN, ...), where users don't have access. The best approach depends on used infrastructure. If you are not able to secure this communication properly, then AuthProxy is not the best auth method for you.
IMHO the best authentication (and single sign on) protocol supported also by Grafana is Open ID Connect (or SAML for Grafana Enteprise). But you will need Identity Provider, which will support these standards.
I have a requirement to download some files stored in a Google Cloud Storage bucket. The challenge is to download it without internet access. Is possible to interact with a Bucket without Internet access? Any suggestions?
Thanks,
Prasanth
No, it wouldn't be possible. You need internet connection to access resources hosted in the Cloud.
You would need to store the files locally or on a physical data storage device in order to access them without the connection.
The only possible option to not use "internet" is to use Dedicated Interconnect where basically you will have a cable from your on-premise to Google's network.
EDIT:
As I understand from the comment you edited, your actual goal is to connect to your GCS bucket from a private VM instance hosted on GCE.
For that you might want to use VPC Service Controls to define the security perimeter around your services and constrain data within a VPC. One of this product's advantages is that the VPC Service Controls provides an additional layer of security by denying access from unauthorized networks, even if the data is exposed by misconfigured Cloud IAM policies.
Here you can find the GCP documentation on configuring VPC Service Controls.
I've got a spring boot app which is connected to mongodb atlas.
Everything is working locally.
I now want to publish this to pivotal cloud foundry.
Secure connection between PCF and atlas
In mongodb atlas I need to open up the firewall an allow certain ip numbers.
How should I configure mongodb atlas to connect to pcf in the most secure way?
Autoconfigure getting in the way
cloud foundry is overriding my connection urls to point to localhost:27017 instead of my atlas cluster.
What is the recommended way to connect to mongodb atlas?
In mongodb atlas I need to open up the firewall an allow certain ip numbers. How should I configure mongodb atlas to connect to pcf in the most secure way?
White listing IP addresses for applications that run on CF is not particularly effective. The reason it's not effective is that you don't know the IP address from which you'll be connecting, because it depends on where Diego decides to run your application. In other words, it depends on the cell where your application is told to run. To compound matters, that will change when you restart / restage your application.
Because the IP can vary, what you end up needing to do is white list all of your Cells. The problem with this and why it's not effective is that you've ended up white listing every app running on the platform.
What you can do to improve the security a bit is to make use of application security groups. ASG's can be used to limit outgoing traffic. You can also control them at the space level. That means you can configure your default running security group to not allow access to your MongoDb server, but you can allow access for individual spaces by binding an ASG to only those spaces with apps that need to talk to your MongoDb servers.
The downside of this approach is that it requires you to be a platform administrator, which means it will only work if you own your CF installation (not going to work for public providers).
More on ASG's here: https://docs.cloudfoundry.org/adminguide/app-sec-groups.html
For public providers, you can use a proxy. To make this work, you need to have your application configured to talk through a proxy when it attempts to access your Mongodb servers. You control the proxies, which have fixed IPs, so you can white list the proxies to allow access to just your app. If you don't want to run your own proxy servers, there are public proxy providers that you can use.
cloud foundry is overriding my connection urls to point to localhost:27017 instead of my atlas cluster. What is the recommended way to connect to mongodb atlas?
It's possible to disable auto configuration. One way is described in the docs here. If you include the Spring Cloud Connectors dependencies and use them manually, then the auto configuration will not run.
https://docs.cloudfoundry.org/buildpacks/java/spring-service-bindings.html#manual
The other option is to tell the Java build pack not to install the auto configuration. You can do that by setting the following environment variable for your application, either with cf set-env or via a manifest.yml file.
Ex: JBP_CONFIG_SPRING_AUTO_RECONFIGURATION='[enabled: false]'
Be careful if you do this as it will disable everything provided by the auto reconfiguration, which includes setting the "cloud" profile for your app. If you use this option to disable auto reconfiguration, you'll probably also want to set SPRING_PROFILES_ACTIVE='cloud' to manually enable the cloud profile.
I suppose your other option is to simply embrace the auto configuration. It's a little confusing / magical at first, but I've found this article to explain it very well.
https://spring.io/blog/2015/04/27/binding-to-data-services-with-spring-boot-in-cloud-foundry
Hope that helps!
How are Cassandra clusters usually built in security way? Should they always be kept locally or are there any security functions that makes it reasonable to open up for external connections to the cluster? As far as I've understand I seems like Cassandra doesn't have any "inbuild security engine" for handling these kind of things. I'm planning on building a service to talk with the Cassandra from, should that connection be made locally (on the same net as the cluster) or from external using the DNS?
Cassandra supports builtin password authentication and authorisation since version 1.2.
User credentials and privileges are kept internally, in system auth tables. This can be viewed as its "inbuild security engine".
As for protecting connections (encryption), since version 1.2, there's SSL support for both internode and client-to-node communication. DataStax Enterprise platform additionally extends that with Kerberos/LDAP support to allow single-sign-on.
Configure a stateful firewall to allow incoming connections, but allow outgoing only if someone requested something from the server. Also C* has inbuilt SSL support, but not all APIs can use the SSL, so you'll have to pick a compatible one.