I have a GitLab repo that generates a static website, pushed to either GitLab Pages or Amazon S3. I want to limit access to this static website to members of a certain GitLab group/sub-group. What is the lowest maintenance way to accomplish this?
Using AWS is permissible for this task, but I want to stop short of deploying this site on its own EKS container or something like that.
GitLab Pages has built-in access controls.
https://docs.gitlab.com/ee/user/project/pages/pages_access_control.html
Related
I created a Azure Static Web App in Azure. The process saved a workflow file in the Github repository and created a URL https://nice-beach-0253b8b10.azurestaticapps.net. How can I change this URL?
You currently can't change the azurestaticapps.net itself. However, you can configure a custom domain (using your own domain provider) or setup a CNAME record.
See more info: https://learn.microsoft.com/en-us/azure/static-web-apps/custom-domain?tabs=azure-dns
Unfortunately, you cannot pick and choose your app URLs. But if you hate only the nice-beach part, you can always create another Static Web App resource and hope for the best as Azure picks a random two-word phrase every time.
Static web apps are just another Azure app service and you should be able to set up custom domains as you normally do for any other app service.
Let's say I have a single page application using React/Node, and I want to deploy that application using a content delivery network to improve load performance.
To do that in Amazon Web Services (AWS) I would need to incorporate different services to work together.
I would need to host my bundled static web page files on amazon's S3 bucket. Then I would need to host my Node API on Elastic Beanstalk. Lastly, I would then need to setup a CloudFront distribution and set my origin to my S3 bucket.
It would look something like this:
Now, if I wanted to do the same thing in Firebase, according to this video tutorial, I can simply setup Firebase Hosting which is backed by their own CDN which gives similar improved load times. Firebase hosting can encompass the entire React/Node application without the need for separation or various services like I did in AWS.
My questions are:
How does Firebase hosting encompass dynamic Node Apps with out the need to separate the front and backend or use various other services?
The point of a CDN is to cache files, so it wouldn't be possible to use a CDN on a Node API right or wrong? If right then how is Firebase using Node app in their CDN?
It seems much simpler to setup on Firebase to serve an entire dynamic app on their CDN compared to AWS, would their be any drawbacks to this or is it just a better service?
Firebase Hosting is only for your static frontend code. But there is a way to connect Firebase Hosting and Cloud Functions to serve dynamic content that is pretty easy to setup.
https://firebase.google.com/docs/hosting/functions
You can think of Firebase Hosting a zero-ish config equivalent to the AWS S3/CloudFront section of the diagram.
I am working on a web site (frontend Vue application and backend NodeJS) for a client and I want to upload it to AWS for the client to see it in action.
However, I do not want the website to be visible to the public yet who may either go to the yet-to-be-marketed domain name, or accidentally stumble upon it.
Besides adding a password box to the web server itself, is there an AWS-specific way to accomplish this? Also, if I serve the frontend directly from S3, then adding a password block to the webserver won't help either. How can I limit access to the S3 frontend in that case?
You can try to restrict access to the http port from specific IPs only. This can be controlled by the inbound rules on your security group assigned to the instance running.
I'll have to read around a little, but I don't think that you can restrict web-access to S3 hosted webpages. At best, you can define IAM roles which govern access to the content; but if the bucket is configured to serve as a static website, you can't control restrictive access.
I'm currently using Azure Websites to deploy my app. I'm currently using two websites each listening to a different branch of my GIT. As seen here.
Now, for it to be perfect, I'm only missing a way to quickly switch between these 2 instances so I could:
Deploy on A
Test the changes on A
VIP Swap A with B
Change code
Deploy on B
Test the changes on B
VIP Swap B with A
...
Anyone has accomplished anything like this?
Thanks!
VIP swapping between a production and a staging deployment is now possible with Azure Web Sites.
It works similarly to how VIP swapping works with Azure Cloud Services.
You can find details on how to set this up and use it in this blog post.
I'd imagine that you'd need to find a DNS provider that could give you access to DNS mapping via an API. This way, you could use a script to call the DNS and swap the C-Names around.
This Stackoverflow post talks about DNS providers that allow an API access: What DNSs have API access?
We are in the process of setting up our IT infrastructure on Amazon EC2.
Assume a setup along the lines of:
X production servers
Y staging servers
Log collation and Monitoring Server
Build Server
Obviously we have a need to have various servers talk to each other. A new build needs to be scp'd over to a staging server. The Log collator needs to pull logs from production servers. We are quickly realizing we are running into trouble managing access keys. Each server has its own key pair and possibly its own security group. We are ending up copying *.pem files over from server to server kind of making a mockery of security. The build server has the access keys of the staging servers in order to connect via ssh and push a new build. The staging servers similarly has access keys of the production instances (gulp!)
I did some extensive searching on the net but couldnt really find anyone talking about a sensible way to manage this issue. How are people with a setup similar to ours handling this issue? We know our current way of working is wrong. The question is - what is the right way ?
Appreciate your help!
Thanks
[Update]
Our situation is complicated by the fact that at least the build server needs to be accessible from an external server (specifically, github). We are using Jenkins and the post commit hook needs a publicly accessible URL. The bastion approach suggested by #rook fails in this situation.
A very good method of handling access to a collection of EC2 instances is using a Bastion Host.
All machines you use on EC2 should disallow SSH access to the open internet, except for the Bastion Host. Create a new security policy called "Bastion Host", and only allow port 22 incoming from the bastion to all other EC2 instances. All keys used by your EC2 collection are housed on the bastion host. Each user has their own account to the bastion host. These users should authenticate to the bastion using a password protected key file. Once they login they should have access to whatever keys they need to do their job. When someone is fired you remove their user account to the bastion. If a user copies keys from the bastion, it won't matter because they can't login unless they are first logged into the bastion.
Create two set of keypairs, one for your staging servers and one for your production servers. You can give you developers the staging keys and keep the production keys private.
I would put the new builds on to S3 and have a perl script running on the boxes to pull the lastest code from your S3 buckets and install them on to the respective servers. This way, you dont have to manually scp all the builds into it everytime. You can also automate this process using some sort of continuous build automation tools that would build and dump the build on to you S3 buckets respectively. Hope this helps..