Skip to main content

Click ops

Whilst the majority of our infra is defined in code, there are some instances where things have been done manually. This is documented here.

Route 53 / Domains​

Domains​

We used route 53 to register our hectare.cloud domain.

We have registerded the domain in prod. Other AWS accounts such as dev all have ownership of their own subdomain to prevent cross account dependencies.

  • For this, in the hectare.cloud hosted zone in prod, there is a NS entry for each environment subdomain, i.e. dev.hectare.cloud. Dev will then have a separate hosted zone for the dev.hectare.cloud domain.
  • There's also an A record in each hosted zone mapping api.{env}.hectare.cloud to the the load balancer host name, which invokes our ECS containers.

AWS Certificate Manager​

An ACM certificate has been created in the console in each environment so that we can serve HTTPS requests.

  ApplicationLoadBalancerHttpListener:
    Type: AWS::ElasticLoadBalancingV2::Listener
    Properties:
      DefaultActions:
        - Type: redirect
          RedirectConfig:
            Protocol: HTTPS
            Port: 443
            Host: '#{host}'
            Path: '/#{path}'
            Query: '#{query}'
            StatusCode: HTTP_301
      LoadBalancerArn: !Ref ApplicationLoadBalancer
      Port: 80
      Protocol: HTTP

  ApplicationLoadBalancerHttpsListener:
    Type: AWS::ElasticLoadBalancingV2::Listener
    Properties:
      DefaultActions:
        - Type: fixed-response
          FixedResponseConfig:
            StatusCode: 404
      LoadBalancerArn: !Ref ApplicationLoadBalancer
      Port: 443
      Protocol: HTTPS
      Certificates:
        - CertificateArn: !FindInMap
            - mEnvironments
            - !Ref pEnvironment
            - CertificateArn

The snippet above shows the load balancer listeners configured. You can see for the HTTPS listener, we have attached the ACM certificate so it can serve HTTPS requests.

Also, the HTTP listener has a force redirect to HTTPS, so that we are only serving via HTTPS.

Secrets Manager​

Our secrets in secrets have been manually provisioned. This is because secrets have to provide a value, when defining them in infra as code, and since these are sensitive information we do not want to hardcode them in.

General use-case for these secrets so far have been to provide the HECTARE env var our container and lambda's need for the platform decryption.

  Environment:
    - Name: HECTARE
      Value: '{{resolve:secretsmanager:hctr/encrypted-config:SecretString:HECTARE}}'

We inject these in directly from secrets manager with the resolve: syntax which reads a particular field from the secret object.

Note: Since these are injected in as env vars, they are visible in the console. If this is a concern, then we can supply the ARN of the secret and do a look-up inside the app to retrieve the actual value. In this case, the HECTARE value is needed on app boot-up so any such middleware would need to be ran immediately.`

IAM users & switch roles to switch between accounts.​

Our IAM users have been manually created in the console. Any new user being onboarded should be added manually to the console in the relevant group in the prod account, they will then have automatic access to the non-prod environments too. (Read more here)

SAM Deployment user and roles​

The SAM deployment user and role have been automatically created using SAM Pipeline. (Read more here )

Elastic function beat​

A deployment role has been created to deploy the Elastic function beat lambda (our Elastic logs shipper) and a permission has been updated so that all log groups have permission to invoke this lambda.

IAM role for our tests​

An IntegrationTestsExecutionRole role has been created in dev which our pipeline assumes when running tests as some tests interact with real AWS resources in dev such as Cognito.

The role has an IntegrationTestsPolicy attached to it. One of the permissions grants all access to any AWS resource with the tag Used_By_Integration_Tests set to true. Currently just our cognito user pool I believe has this tag set. If there's other resources needed for the tests, then it is just a case of applying that tag and it should work.

The exception of that is for S3 access, as the resource is the object in the bucket itself so the tag solution is not feasible.