- [Instructor] I've been playing it fast and loose
with security throughout this course,
and while that's fine for creating small examples
that are easy to absorb in the context of learning,
it is something to be aware of,
so I just want to take this opportunity
to explicitly call it out.
I used HTTP instead of HTTPS,
because this is a course on deployment,
not a course on HTTPS.
I used overly broad AWS permissions
to help the demos flow more quickly.
And I left my ECS cluster open to the world
while I was recording.
Security measures should always be taken in proportion
to what they're protecting.
Though it's really important to
pay attention as what they're protecting grows,
and when that calculus tips the other way.
A few common best practices,
don't store credentials in code.
This one is so important to me,
I didn't even do that in this course,
even to shorten the examples.
I've been burned.
In this course we used instance roles for everything in AWS.
We didn't store credentials in our code,
and our sample project being stateless,
has no use for AWS credentials, so it has nothing to steal,
which makes it even better.
Although, not having any credentials to guard,
doesn't usually last long, as projects grow.
Likewise, don't store database passwords in code.
If our sample project had had a database,
and had needed a password,
I would've used a credential store
like AWS SecureSessionManager.
They are great for this,
and they're reasonably easy to use.
Totally worth it.
Mostly because when things go really wrong,
if all your passwords are stored
in the secure credential storage system,
you can change them really fast all at once.
And I've learned recently that that recovery time
can be worth a lot.
So, likewise, don't store your credentials on the host.
Jenkins is a target.
Jenkins is a reasonably secure target
but it's still a target.
We stored an SSH key on Jenkins,
and we were careful to store an SSH deploy key
for a single project with read-only access,
so that we limit what it can do.
These reasonable precautions were pretty easy,
and we could've done better.
Jenkins has a secure credential store built in,
so let's take a quick look.
Over here in our Jenkins instance,
it's right there on the front page, credentials.
Credentials are divided into scopes,
and those scopes can be used to limit which parts of the
Jenkins systems have access to which secrets,
which can get really useful as a Jenkins instance grows
to hundreds of projects managed by 50 or 100 people.
Going into the Global scope,
I see there are no credentials here,
but if you go to add them,
there's a whole variety of different kinds
of credentials it can store.
SSH, secret key, certificates, plain old secret text,
and then if you can configure jobs
to inject these credentials where they're required,
without having to store them in the job config files.
It provides a decent layer of security
and is a useful precaution.
Definitely worth doing.
And as a general goal, try to keep security,
at least somewhere in your mind,
as you go about this process.