App-FargateStack

 view release on metacpan or  search on metacpan

README.md  view on Meta::CPAN

      command: /usr/local/bin/my-worker.pl
      type: task
      schedule: cron(00 15 * * * *)   
      bucket:
        name: my-worker-bucket
      queue:
        name: my-worker-queue
      environment:
        ENVIRONMENT=prod
      secrets:
        db_password:DB_PASSWORD
      efs:
        id: fs-abcde12355
        path: /
        mount_point: /mnt/my-worker

Adding new resources would normally require you to update your
policies to allow your worker to access these resource. However, the
framework automatically detects that the policy needs to be updated
when new resources are added (even secrets) and takes care of that for
you.

README.md  view on Meta::CPAN

Environment variable values are treated literally; shell-style
expressions such as ${VAR} are not interpolated. If you need dynamic
values, populate them explicitly in the configuration or use the
`secrets:` block for sensitive data.

This mechanism is ideal for non-sensitive configuration such as
runtime flags, environment names, or log levels.

## SECURITY NOTE

Avoid placing secrets (such as passwords, tokens, or private keys) directly in the
`environment:` section. That mechanism is intended for non-sensitive configuration
data.

To securely inject secrets into the task environment, use the `secrets:` section
of your task configuration. This integrates with AWS Secrets Manager and ensures
secrets are passed securely to your container.

## INJECTING SECRETS FROM SECRETS MANAGER

To inject secrets into your ECS task from AWS Secrets Manager, define a `secrets:`
block in the task configuration. Each entry in this list maps a Secrets Manager
secret path to an environment variable name using the following format:

    /secret/path:ENV_VAR_NAME

Example:

    task:
      apache:
        secrets:
          - /my-stack/mysql-password:DB_PASSWORD

This configuration retrieves the secret value from `/my-stack/mysql-password`
and injects it into the container environment as `DB_PASSWORD`.

Secrets are referenced via their ARN using ECS's native secrets mechanism,
which securely injects them without placing plaintext values in the task definition.

## BEST PRACTICES

Avoid placing secrets in the `environment:` block. That block is for non-sensitive
configuration values and exposes data in plaintext.

lib/App/FargateStack/Builder/Secrets.pm  view on Meta::CPAN

      $secret_arn = $secrets_manager->find_secret_arn($path);

      log_die( $self, 'Secret not found in Secrets Manager: %s (env var: %s)', $path, $env_name )
        if !$secret_arn;
    }
    else {
      ( $secret, $secret_arn ) = %{$secret};
      ( $path, $env_name ) = split /:/xsm, $secret;
    }

    log_die( $self, 'secret value must be path:env-name, not %s, example: /mysql/password:DB_PASSWORD', $secret )
      if !$env_name || !$path;

    push @secrets, { name => $env_name, valueFrom => $secret_arn };
  }

  $self->set_secrets( \@secrets );  # adding new secrets should
                                    # trigger updating policy
  return \@secrets;
}

lib/App/FargateStack/Pod.pm  view on Meta::CPAN

   command: /usr/local/bin/my-worker.pl
   type: task
   schedule: cron(00 15 * * * *)   
   bucket:
     name: my-worker-bucket
   queue:
     name: my-worker-queue
   environment:
     ENVIRONMENT=prod
   secrets:
     db_password:DB_PASSWORD
   efs:
     id: fs-abcde12355
     path: /
     mount_point: /mnt/my-worker

Adding new resources would normally require you to update your
policies to allow your worker to access these resource. However, the
framework automatically detects that the policy needs to be updated
when new resources are added (even secrets) and takes care of that for
you.

lib/App/FargateStack/Pod.pm  view on Meta::CPAN

Environment variable values are treated literally; shell-style
expressions such as ${VAR} are not interpolated. If you need dynamic
values, populate them explicitly in the configuration or use the
C<secrets:> block for sensitive data.

This mechanism is ideal for non-sensitive configuration such as
runtime flags, environment names, or log levels.

=head2 SECURITY NOTE

Avoid placing secrets (such as passwords, tokens, or private keys) directly in the
C<environment:> section. That mechanism is intended for non-sensitive configuration
data.

To securely inject secrets into the task environment, use the C<secrets:> section
of your task configuration. This integrates with AWS Secrets Manager and ensures
secrets are passed securely to your container.

=head2 INJECTING SECRETS FROM SECRETS MANAGER

To inject secrets into your ECS task from AWS Secrets Manager, define a C<secrets:>
block in the task configuration. Each entry in this list maps a Secrets Manager
secret path to an environment variable name using the following format:

  /secret/path:ENV_VAR_NAME

Example:

  task:
    apache:
      secrets:
        - /my-stack/mysql-password:DB_PASSWORD

This configuration retrieves the secret value from C</my-stack/mysql-password>
and injects it into the container environment as C<DB_PASSWORD>.

Secrets are referenced via their ARN using ECS's native secrets mechanism,
which securely injects them without placing plaintext values in the task definition.

=head2 BEST PRACTICES

Avoid placing secrets in the C<environment:> block. That block is for non-sensitive
configuration values and exposes data in plaintext.

share/README.md  view on Meta::CPAN

      command: /usr/local/bin/my-worker.pl
      type: task
      schedule: cron(00 15 * * * *)   
      bucket:
        name: my-worker-bucket
      queue:
        name: my-worker-queue
      environment:
        ENVIRONMENT=prod
      secrets:
        db_password:DB_PASSWORD
      efs:
        id: fs-abcde12355
        path: /
        mount_point: /mnt/my-worker

Adding new resources would normally require you to update your
policies to allow your worker to access these resource. However, the
framework automatically detects that the policy needs to be updated
when new resources are added (even secrets) and takes care of that for
you.

share/README.md  view on Meta::CPAN

Environment variable values are treated literally; shell-style
expressions such as ${VAR} are not interpolated. If you need dynamic
values, populate them explicitly in the configuration or use the
`secrets:` block for sensitive data.

This mechanism is ideal for non-sensitive configuration such as
runtime flags, environment names, or log levels.

## SECURITY NOTE

Avoid placing secrets (such as passwords, tokens, or private keys) directly in the
`environment:` section. That mechanism is intended for non-sensitive configuration
data.

To securely inject secrets into the task environment, use the `secrets:` section
of your task configuration. This integrates with AWS Secrets Manager and ensures
secrets are passed securely to your container.

## INJECTING SECRETS FROM SECRETS MANAGER

To inject secrets into your ECS task from AWS Secrets Manager, define a `secrets:`
block in the task configuration. Each entry in this list maps a Secrets Manager
secret path to an environment variable name using the following format:

    /secret/path:ENV_VAR_NAME

Example:

    task:
      apache:
        secrets:
          - /my-stack/mysql-password:DB_PASSWORD

This configuration retrieves the secret value from `/my-stack/mysql-password`
and injects it into the container environment as `DB_PASSWORD`.

Secrets are referenced via their ARN using ECS's native secrets mechanism,
which securely injects them without placing plaintext values in the task definition.

## BEST PRACTICES

Avoid placing secrets in the `environment:` block. That block is for non-sensitive
configuration values and exposes data in plaintext.