Docker with Angular Q&A

[00:00:00]
>> I did see in the repo that you had a default configuration for nginx. Are you using that anywhere in this example?
>> So I'm not using it but there are times where I will use nginx. So I think this is I might've just carried this over so I think engine X is another good kind of an example to use.

[00:00:28]
But in this case, not so very clever so the question is in the repo, there's an engine X, a config file am I using that? The answer is no, not in this example I'm not.
>> Other times where I guess in which point would you wanna use NGINX.

[00:00:46]
>> I don't have a good answer in a sense that in case we'll use NGINX for this. Let me say this, if I was going to use a production grade web server I would use nginx all the time. So I'll leave it at that. Next question.
>> For both viable options you mentioned in terms of the static files in s3 or using Docker.

[00:01:14]
What would you do about using API keys public are an API key from like Google Maps or something that you wanna keep private.
>> First, let me tell you what not to do with them. Do not put those in your Git repo like never, ever, ever leak your keys into GitHub.

[00:01:37]
So typically what I will do Is are used, either hashey Corp vault or Amazon key manager to hold those and so in that way you never even have to touch them is that you can rotate, those keys out and then just pull those into your application is your building those.

[00:01:59]
Another way to handle that is if you're making like a third party API call that requires the key is I'll put that particular function into like a lambda and then you can put that key right into the AWS console. So the answer is Never ever, ever put it in your code and check it in ever, like never leak your keys, the minute you do that, you have to like reset, start over.

[00:02:29]
It's one of the fastest ways to get hacked. The best answer is to put those keys in either like AWS key manager HashiCorp vault or some secrets manager. From there, kinda the next piece is, I have put keys inside of AWS Lambda, what allows you to define that key variable, right with inside of that Lambda.

[00:02:56]
But even then, within the lambda you can still pull that key from the key manager. And so I would really say use vault or a key manager to hold that data and avoid passing those around at all costs because that is, that's a really good way to get hacked in a really bad way.

[00:03:17]
>> Sorry, got one more question about the keys you said that you would incorporate them in the build process if it's. But wouldn't that still make it public in the client side application?
>> I would say no, depending how you set up the build, so in other words, you can use within the build process but most of them will integrate over to like you have AWS Build.

[00:03:44]
I don't know, a lot of people that are using AWS Build but there's a way to actually build within it. But, for you to actually pull those keys in, and from AWS or from your vault or whatever you're doing inside of the build process and not expose them directly.

[00:04:02]
And so, to that end is that, like if you have very sensitive keys, they really shouldn't be in the front end period. You're really what you need keys for us like those need to be on the server side and the goal should never see the light of day so nobody should ever see your build process.

[00:04:19]
And nobody should really have access to that so they should be behind layers of abstraction. But within the build process, you should be able to pull those variables down and in, run the build and do that, so in terms of like, if somebody hacks like your GitHub because you can put like keys in there as well, so you can add those in.

[00:04:41]
If somebody hacked like your GitHub account they might have access to it. But it's creating that layer of abstraction that like they should never at any point, be visible to anybody who doesn't have appropriate access.