Append another CloudFront Function to the created Distribution in static-website construct

[InvisibleKind]

Hello again,

I'm making forward my journey to the serverless world :D

One of my next goals is to add Basic Auth to Cloudfront distributions, created in DEV and STAGE environments, and Cloudfront Functions is the perfect place for this functionality.

So I've added it under the resources:

resources:
  Resources:
    basicAuth:
      Type: AWS::CloudFront::Function
      Properties:
        AutoPublish: true
        FunctionCode: "function handler(event) {
    var request = event.request;
    var headers = request.headers;
    var authUser = 'xxx';
    var authPass = 'yyy;
    var authString = 'Basic ' + (authUser + ':' + authPass).toString('base64');
    if (typeof headers.authorization == 'undefined' || headers.authorization.value != authString) {
        var response = {
            statusCode: 401,
            statusDescription: 'Unauthorized',
            headers: {
                'www-authenticate': {value:'Basic'}
            },
        };
        return response;
    }
    return request;
};"
        FunctionConfig:
          Comment: 'serverless Basic Auth protection to prevent non-athorised access to dev and stage instances'
          Runtime: cloudfront-js-1.0
        Name: ${self:service}-${self:custom.stage}-basic-auth

The function is created, but I can't figure out, how can I attach it to the Cloudfront Distribution, created by lift. I assume I should do it in resources.extensions section and/or reference somehow with !GetAtt, but have no idea how.

Is there a way to achieve what I need?

[InvisibleKind]

Also a bonus question: can I pass user and pass per env variables or per Secrets somehow instead of hardcoding them in the function?

[fredericbarthelet]

Unfortunately, CloudFront functions needs to be synchronous, and therefore cannot rely on third party services (like the Parameter Store from SSM or Secret Manager) to handle secret management. AFAIK you also can set environnement variables for CloudFront functions.

[mnapoli]

AFAIK you also can set environnement variables for CloudFront functions.

Don't you mean "you also can't set environment variables"? Because I don't think you can.

[InvisibleKind]

Thank you for your answers. That's a pity, that the Secrets Manager and env vars can't be used in Cloudfront Functions in runtime, however I've found a way to extract login and password to env variables in a build time. I've used CloudFormation parameters for that.

As a result the login and password are not hardcoded and are not stored in git, which was important for me.
They are still visible in CloudFormation template and in a function itself, but it is already better than before, because not exposed to every developer, but only to those, who have access to AWS Prod account and CI/CD system.

To make it work I've added following section to provider:

stackParameters:
    - ParameterKey: CloudFrontUsername
      ParameterValue: ${env:AWS_CF_USERNAME, self:custom.cloudfront.defaultUsername}
    - ParameterKey: CloudFrontPassword
      ParameterValue: ${env:AWS_CF_PASSWORD, self:custom.cloudfront.defaultPassword}

This to resources:

Parameters:
    CloudFrontUsername:
      Description: 'Basic Auth username in Cloudfront'
      Type: String
    CloudFrontPassword:
      Description: 'Basic Auth password in Cloudfront'
      Type: String
      NoEcho: true

FunctionCode changed to this:

FunctionCode: !Sub "function handler(event) {
    var request = event.request;
    var headers = request.headers;
    var authUser = '${CloudFrontUsername}';
    var authPass = '${CloudFrontPassword}';
    var authString = 'Basic ' + (authUser + ':' + authPass).toString('base64');
    if (typeof headers.authorization == 'undefined' || headers.authorization.value != authString) {
        var response = {
            statusCode: 401,
            statusDescription: 'Unauthorized',
            headers: {
                'www-authenticate': {value:'Basic'}
            },
        };
        return response;
    }
    return request;
};"

And extended my custom section:

cloudfront:
    defaultUsername: username
    defaultPassword: pass1234!

[fredericbarthelet]

Hey @InvisibleKind, thanks for reporting your use case :) !

Lift uses CDK under the hood. CDK generates logical id for each resources provisioned through a construct (in your case, for exemple, for the CloudFront distribution you're trying to reference). Those generated logical ids contains a small hash at the end to prevent collision with similar path to resources.

You can use resources.extensions to extend generated CloudFormation template, but you'll have to "hardcode" this generated hash within your template. Please be aware that changing construct name can affect generated hash.

We are thinking of a way to extend construct on a more reliable basis (without hardcoding the generated hash), but in the mean time, you always have the possibility to eject from Lift, version generated CloudFormation and update the CloudFront logical id to match your liking. Once you've done so, you can specify the association using the FunctionAssociation property.

[mnapoli]

👍 I would suggest ejecting too.

In the future, the best option might be to write a custom construct that extends the existing construct (#52).

Regarding the feature itself (auth protection on static websites), it was also requested in #5 (comment). I've opened #79 to track that feature request: please add a 👍 on the issue, we use those to gauge interest on new features.

[InvisibleKind]

Thank you @fredericbarthelet and @mnapoli for your responses.
I've decided to connect the function by hand and not to put hardcoded stuff to the serverless configuration, since it is only 1-time action for 2 of 3 stable environments and for temporary environments, which are created on MRs and destroyed after MR is accepted, it is not an issue, because their URLs are not known and are kind of cryptic (default CloudFront URL), and they leave not for a long time to be found out.
But it is good to know, that there is a way to use it in a template if needed.

And yes - I've voted for the Feature :)