move to SSM (from S3) for config/secrets

[twrichards]

No description provided.

[akash1810]

IIRC this repository publishes libraries. In this PR we're adding some infrastructure; how would it differ from https://github.com/guardian/login.gutools?

[twrichards]

IIRC this repository publishes libraries. In this PR we're adding some infrastructure; how would it differ from guardian/login.gutools?

guardian/login.gutools is a play application that provides a minimal way to login (with panda) and also provides an emergency mode when Google is down.

The infrastructure being added in this PR is to define some per stage SSM params (to ultimately replace the pan-domain-auth-settings S3 bucket, which was manually created, has a manually maintained access policy for cross-account access and has directories for stages). The primary motivation for SSM is to make use of the secret rotation library (SSM based) within the panda library to be able to rotate the key seamlessly (i.e. tolerate old key for a grace period) without impact to all the running tools. It made sense to me to co-locate this (and any future lambda for automatic rotation) in the pan-domain-authentication repo, rather than login.gutools which is its own service with its own purpose (albeit related).

I'm working with @rtyley on this.

[akash1810]

Thanks for the context @twrichards, super helpful! The plan sounds good, and discrete enough from login.gutools too.

has a manually maintained access policy for cross-account access

You might want to consider how to achieve IaC for this. https://github.com/guardian/private-infrastructure-config might be useful for keeping AWS account IDs (private information) out of this public repository. IIRC the current policy allows any IAM role in any of the listed accounts access. Might this be too broad, with an alternative being to list specific services? Maybe using tags to differentiate?

[twrichards]

You might want to consider how to achieve IaC for this. guardian/private-infrastructure-config might be useful for keeping AWS account IDs (private information) out of this public repository. IIRC the current policy allows any IAM role in any of the listed accounts access. Might this be too broad, with an alternative being to list specific services? Maybe using tags to differentiate?

Indeed I was planning on using guardian/private-infrastructure-config (in fact it was extra motivation to define this new infra with CDK - unlike https://github.com/guardian/editorial-tools-platform/blob/main/cloudformation/composer-account/login.gutools/login-tool.yaml).

That's a good point about the broadness of access, I will explore using tags (to at least limit by Stage) it would be quite nice too, to have a single place where access is defined in all accounts - but I will try to strike a pragmatic balance.

[github-actions]

Deploy build 64 of pan-domain-authentication to CODE

All deployment options

• Deploy build 64 of pan-domain-authentication to CODE
• Deploy parts of build 64 to CODE by previewing it first
• What's on CODE right now?

---

From guardian/actions-riff-raff.