Now, of course, it's a lot easier to understand these concepts when you're actually doing the hands-on work. Let me show you a little bit more about security, and calling AWS APIs from a more hands-on perspective. I'll go to Secrets Manager, and you'll see that I have a value here. Let's go ahead and click this. I'm just going to click 'Retrieve secret value'. You'll see that I have a string here. This is stored in Secrets Manager, and for our purposes, you can assume that this is going to be an API key, perhaps a database password or something sensitive that you don't want hard coded somewhere, or even worse, in your code repository just sitting there. However, you do need this value, for whatever purpose, within your container. 

So, I'm just going to copy this ARN, and I'll go back to ECS here to show you. I'll go to Task definitions, and I believe the one we're running is example-task. I can confirm this because it says nginx:latest here. Let me show you how. Click 'Create new version' of this particular task definition, and you'll see that there's a section here that says Add environment variable. Let's go ahead and click that. Now you can insert a value here. Let me show you, actually, do a couple of them.

Let's say I want to add, let's say DBA_USERNAME, for example, and it's a value type, so I'll just type dbo, for example. But as I mentioned, it's not great to hard code values that you know that might change over time, or they might be sensitive that they're probably best stored in the Parameter Store or Secrets Manager. So, how do you go about that? In that case, you'll give it a key, just like that, let's say DBA_PASSWORD, for example, and instead of Value, you're going to choose ValueFrom. And then, we're going to paste the ARN of our specific secret. That's really all there is to it. So, in this case, so in your container, you will look for this environment variable. 

You will pull it from the system, just like in any other Linux environment you will put this value, and it should have the sensitive data that you're looking for, and it's only going to be available at runtime. It's not going to be hard coded anywhere. Now there's one more thing that I need to make sure you understand. Down here, you're going to see a Task role, and you're going to see a Task execution role. The difference is, if you read the description, the Task execution role is used by the container agent, that is the AWS application that is managing your containers. That's not what you want. You want to make sure that you use the Task role because it says a task IAM role allows containers in the task to make API request to AWS services.

So, chances are if you are in AWS and you're running container, you are probably going to need the Task role to access those services. In our case, in this example, we're trying to access Secrets Manager, so you need to make sure that you assign a Task role that has permission to access that particular secret, or perhaps just full access to Secrets Manager, which would probably be a bad practice. If you do so, try to keep the settings to least privilege when it comes to IAM security, and this would be the place to do that. You would go to IAM, define the task role, and you would just pick it from this list while you're creating your task definition. Speaking of task definition, let's go over the detail of all these fields that are part of the task definition, which is really the last component that you need to understand before you can start running your own containers on ECS Fargate.