Hoping someone here can help.
I have a use case, where I am exposing an NGINX ingress controller with both internal and external LBs. The internal LB is used for things that sit outside of K8S, but within the same network to talk via ingress to things inside K8S, whilst still leveraging our NGINX configurations.
The challenge :
I want to be able to restrict endpoints which we are exposing only to internal systems, so that they can not be accessed via the external LBs (it would be pretty easy for someone to hit the external LB with the correct host headers otherwise and still access the applications behind them).
Does anyone know of any way to do this, which does not involve having to stand up a duplicate NGINX deployment entirely. IE, was hoping to be able to have an ingress class defined which would use exclusively the service with the internal LB rather than the external one.
Related
I have used a few reverse proxies, such as HAProxy, Traefik and Kong. And when I started working with Kubernetes, I was confused by the concept of Ingress. Aren't the routings to back-end resources also achievable via reverse proxies? What is the purpose of using Ingress?
You can use any reverse proxy you want (for example kube-nginx-proxy).
In this case you need to perform some configuration steps, which could take a lot of time.
Ingress is specially designed for fast setup. The only thing you should do is to describe your configuration using yaml, which is easier and faster than third-party solutions.
Also you can use, for example, Istio for this purpose, in which case Ingress is already integrated.
I'm building a website, however the URL for the website is likely to change.
How can I load resources in the front end if the domain and installation directory is likely to change?
Now that I'm starting to get deep into building the backend I have some issues.
The url is about to change, what do I do now?
I can use PHP to get the current domain and have a preset installation directory. Then load it from a variable every time I need to load a resource.
Is there any other solutions, what would you recommend?
I'm talking about resources loaded through the browser, not ones loaded through php.
If the resources are housed under the same domain as your php app, you can simply remove the protocol and hostname from those links and let the browser figure it out.
If the resources are hosted on a different hostname (or via a different protocol - http vs. https for example) then your solution of using a variable is probably the best course.
I am building a Spring Web Application hosted on Elastic Beanstalk. I use S3 to store user uploaded images which works great. What I don't understand is how fetching images from S3 to the client work. I found three alternatives.
1.Get the image in a controller and send it to the client. Like this:
S3Object object = amazonS3Client.getObject("bucketname", "path/to/image");
2.Open up all images and reach it directly by an URL in the client. Something like this:
<img src="http://aws.amazon.com/bucket/path/to/image.jpg">
3.Use signed download URLs that only working for a certain time. Like this:
GeneratePresignedUrlRequest request = new GeneratePresignedUrlRequest("bucketname", "path/to/image");
String url = conn.generatePresignedUrl(request)
Im not sure which approach to go for. Routing it through the web server seems unnecessary, since it loads the server. Open the URLs to anyone might higher requests and costs since anyone can use the images. And the third way is new to me, haven't really seen anyone practising this which makes me insecure if this is really the way to go.
So, how is this usually done?
And how is this used in the development environment versus production environment. I guess its not changing? Or is it common to use spring profiles to change the location of static content while developing and only use S3 for production?
If your hosting Javascript, CSS on S3, is it then most common to go for approach 2 and open them up for everyone?
For me it depends upon the requirements you have for access control for images uploaded by a user.
If the images are non-sensitive i.e. it wouldn't really matter if someone else got hold of another user's images, then I would go for approach 2.
If on the other hand it would be a disaster if someone managed to get hold of another user's images, then I would go for approach 3 (or some other form of expiring token access to the images).
The last time I did this I went for approach 2 because the images were non-sensitive. To try and prevent people from discovering images, we did apply a hashing function to the name of the image, but again I wasn't massively concerned about this. In either case, a well defined bucket structure that can be easily worked out by the application when constructing the URL for an image is useful. So for you, perhaps consider something like:
s3:bucket_name/images/users/<hashed_and_salted_user_name>/<user_images>
As for you request regarding dev vs prod environments, then matching a bucket name to the Spring profile is the approach we used. So for example:
s3:bucket_name/prod/images/users/user/foo.jpg
s3:bucket_name/dev/images/users/user/foo.jpg
As you can probably guess we had Spring profiles named "prod" and "dev". The code for building image URLs took into account the name of the current Spring profile when creating the URL. Gives a nice separation between environments.
In terms of CSS and Javascript, then I tend to host obfuscated/minified versions in the production S3 buckets, and full versions in the dev/test buckets (mainly for performance rather that trying to hide code). In addition I'd use some sort versioning/naming structure in how you host CSS/Javascript in S3 so that you can determine what "version" of resources your app is using. So for example:
s3:bucket_name/css/app-1.css
s3:bucket_name/css/app-2.css
The version of the CSS/Javascript resources is updated each time you push a new version into production.
By going down this path you kinda look at S3 as the final resting place for a piece of Javascript/CSS when it is ready to go into the wide world of production. Once there, you know it will never change. If CSS/Javascript does change, then the user has to fetch a new resource from S3 as the version will be incremented. You can hook this into your build process so that your main app is always referencing the latest version of CSS/Javascript. I found this has two useful functions:
Makes it very easy to determine which version of a resource your application is running with
Makes it very easy to cache resources (either with browser or something like CloudFront) as you know they will never change
Hope that helps.
I've got a few HTML pages with the requisite images, css and other bits and pieces, all static content no CGI required. I currently host it on an Amazon EC2 image that I need to have up and running for a different application. Ideally I'd like to move the hosting of the static content off the EC2 image so that it's independent of any single EC2 instance. I'd like to host it on one of the free or at least pay as you go cloud options.
The options I've come across are:
Windows Azure, in this case I haven't been able to get .html pages working and even if it is possible would it mean I'd have to update the whole Windows Azure app everytime I needed to update an image? Or is there an easy way static web content could be served up from Azure blobs?
Amazon's S3, I think I'd have to put fully qualified URL's into each HTML page for each image, css etc. file but that wouldn't be too bad. This seems like a reasonable option.
Google's App Engine, only spent 10 minutes looking at it but it seems like it would work as well.
Wordpress, I could just incorporate the HTML into a wordpress blog site but I find the themes a little bit too restrictive, pages can only be so wide etc.
Is there an easier way?
Update:
After some further investigation the two best ways I found are the S3 approach as described by Sug and Windows Azure Blob storage (rather than a Windows Azure service).
The difference between S3 and Azure Blobs is how the CNAME can be managed:
For S3 you'll end up with a CNAME like mybucket.mydomain.com
For Azure you'll end up with a CNAME like *.mydomain.com where * represents whatever you like. To access blobs the path is then *.mydomain.com/container/.
So S3 dictates the CNAME host but gives full flexibility on the resource path. Azure gives full flexibility on the CNAME host but dictates the first part of the resource path.
For serving only static files, using services like AppEngine or Azure will be over kill.
The simplest solution will be to use AWS S3:
1) No coding required
2) Pricing
3) You can easily map a bucket to your own domain or subdomain.
4) Free client tools to manage your buckets as it was dead simple filesystem.
I personally use S3Fox but there are many others (BucketExplorer is another example)
“S3 dictates the CNAME host”
Amazon has a CDN service called CloudFront, that uses an S3 bucket for storage. You only pay for S3 data transfer (I think).
Your bucket contents are copied to Amazon’s CDN, meaning superfast access from around the world. However, because it’s a CDN, files are automatically cached for a long time (so there’s a delay when re-naming or deleting files).
Just using an S3 bucket, and setting up another domain to point to the bucket via a CNAME, might be the best idea.
For simple sites like this, I've had good experiences with Nearly Free Speech.Net.
GitHub.com pages. You just need to know Git basics, check out the gh-pages branch, and put the static content there. It will be available at http://your-name.github.io/your-project/
For example, this is my project's file.
When browsing through the internet for the last few years, I'm seeing more and more pages getting rid of the 'www' subdomain.
Are there any good reasons to use or not to use the 'www' subdomain?
There are a ton of good reasons to include it, the best of which is here:
Yahoo Performance Best Practices
Due to the dot rule with cookies, if you don't have the 'www.' then you can't set two-dot cookies or cross-subdomain cookies a la *.example.com. There are two pertinent impacts.
First it means that any user you're giving cookies to will send those cookies back with requests that match the domain. So even if you have a subdomain, images.example.com, the example.com cookie will always be sent with requests to that domain. This creates overhead that wouldn't exist if you had made www.example.com the authoritative name. Of course you can use a CDN, but that depends on your resources.
Also, you then don't have the ability to set a cross-subdomain cookie. This seems evident, but this means allowing authenticated users to move between your subdomains is more of a technical challenge.
So ask yourself some questions. Do I set cookies? Do I care about potentially needless bandwidth expenditure? Will authenticated users be crossing subdomains? If you're really concerned with inconveniencing the user, you can always configure your server to take care of the www/no www thing automatically.
See dropwww and yes-www (saved).
Just after asking this question I came over the no-www page which says:
...Succinctly, use of the www subdomain
is redundant and time consuming to
communicate. The internet, media, and
society are all better off without it.
Take it from a domainer, Use both the www.domainname.com and the normal domainname.com
otherwise you are just throwing your traffic away to the browers search engine (DNS Error)
Actually it is amazing how many domains out there, especially amongst the top 100, correctly resolve for www.domainname.com but not domainname.com
There are MANY reasons to use the www sub-domain!
When writing a URL, it's easier to handwrite and type "www.stackoverflow.com", rather than "http://stackoverflow.com". Most text editors, email clients, word processors and WYSIWYG controls will automatically recognise both of the above and create hyperlinks. Typing just "stackoverflow.com" will not result in a hyperlink, after all it's just a domain name.. Who says there's a web service there? Who says the reference to that domain is a reference to its web service?
What would you rather write/type/say.. "www." (4 chars) or "http://" (7 chars) ??
"www." is an established shorthand way of unambiguously communicating the fact that the subject is a web address, not a URL for another network service.
When verbally communicating a web address, it should be clear from the context that it's a web address so saying "www" is redundant. Servers should be configured to return HTTP 301 (Moved Permanently) responses forwarding all requests for #.stackoverflow.com (the root of the domain) to the www subdomain.
In my experience, people who think WWW should be omitted tend to be people who don't understand the difference between the web and the internet and use the terms interchangeably, like they're synonymous. The web is just one of many network services.
If you want to get rid of www, why not change the your HTTP server to use a different port as well, TCP port 80 is sooo yesterday.. Let's change that to port 1234, YAY now people have to say and type "http://stackoverflow.com:1234" (eightch tee tee pee colon slash slash stack overflow dot com colon one two three four) but at least we don't have to say "www" eh?
There are several reasons, here are some:
1) The person wanted it this way on purpose
People use DNS for many things, not only the web. They may need the main dns name for some other service that is more important to them.
2) Misconfigured dns servers
If someone does a lookup of www to your dns server, your DNS server would need to resolve it.
3) Misconfigured web servers
A web server can host many different web sites. It distinguishes which site you want via the Host header. You need to specify which host names you want to be used for your website.
4) Website optimization
It is better to not handle both, but to forward one with a moved permanently http status code. That way the 2 addresses won't compete for inbound link ranks.
5) Cookies
To avoid problems with cookies not being sent back by the browser. This can also be solved with the moved permanently http status code.
6) Client side browser caching
Web browsers may not cache an image if you make a request to www and another without. This can also be solved with the moved permanently http status code.
There is no huge advantage to including-it or not-including-it and no one objectively-best strategy. “no-www.org” is a silly load of old dogma trying to present itself as definitive fact.
If the “big organisation that has many different services and doesn't want to have to dedicate the bare domain name to being a web server” scenario doesn't apply to you (and in reality it rarely does), which address you choose is a largely cultural matter. Are people where you are used to seeing a bare “example.org” domain written on advertising materials, would they immediately recognise it as a web address without the extra ‘www’ or ‘http://’? In Japan, for example, you would get funny looks for choosing the non-www version.
Whichever you choose, though, be consistent. Make both www and non-www versions accessible, but make one of them definitive, always link to that version, and make the other redirect to it (permanently, status code 301). Having both hostnames respond directly is bad for SEO, and serving any old hostname that resolves to your server leaves you open to DNS rebinding attacks.
Apart from the load optimization regarding cookies, there is also a DNS related reason for using the www subdomain. You can't use CNAME to the naked domain. On yes-www.org (saved) it says:
When using a provider such as Heroku or Akamai to host your web site, the provider wants to be able to update DNS records in case it needs to redirect traffic from a failing server to a healthy server. This is set up using DNS CNAME records, and the naked domain cannot have a CNAME record. This is only an issue if your site gets large enough to require highly redundant hosting with such a service.
As jdangel points out the www is good practice in some cookie situations but I believe there is another reason to use www.
Isn't it our responsibility to care for and protect our users. As most people expect www, you will give them a less than perfect experience by not programming for it.
To me it seems a little arrogant, to not set up a DNS entry just because in theory it's not required. There is no overhead in carrying the DNS entry and through redirects etc they can be redirected to a non www dns address.
Seriously don't loose valuable traffic by leaving your potential visitor with an unnecessary "site not found" error.
Additionally in a windows only network you might be able to set up a windows DNS server to avoid the following problem, but I don't think you can in a mixed environment of mac and windows. If a mac does a DNS query against a windows DNS mydomain.com will return all the available name servers not the webserver. So if in your browser you type mydomain.com you will have your browser query a name server not a webserver, in this case you need a subdomain (eg www.mydomain.com ) to point to the specific webserver.
Some sites require it because the service is configured on that particular set up to deliver web content via the www sub-domain only.
This is correct as www is the conventional sub-domain for "World Wide Web" traffic.
Just as port 80 is the standard port. Obviously there are other standard services and ports as well (http tcp/ip on port 80 is nothing special!)
Imagine mycompany...
mx1.mycompany.com 25 smtp, etc
ftp.mycompany.com 21 ftp
www.mycompany.com 80 http
Sites that don't require it basically have forwarding in dns or redirection of some-kind.
e.g.
*.mycompany.com 80 http
The onlty reason to do it as far as I can see is if you prefer it and you want to.