Rechten voor woweb om de bucket te vullen

[joostvanderborg]

De websitebucket moet vanuit de GitHub action die de component library build gevuld kunnen worden. Woweb richt dit in, maar moet dus toegang tot de bucket hebben. Zij gaan in week 22 inrichten, dan moet er in ieder geval een bucket beschikbaar zijn (als het niet in dit project lukt, desnoods in sandbox o.i.d.).

Het project is uitgerold en beschikbaar op https://componenten-dev.component-library-dev.csp-nijmegen.nl (die een fout geeft want bucket is leeg).

[joostvanderborg]

@marnixdessing Er moet naar de bucket (https://github.com/GemeenteNijmegen/component-library-infra/blob/development/src/WebsiteBucket.ts) geschreven kunnen worden, waarschijnlijk vanuit een GitHub action. Dat vereist access key enzo.

Wat hebben we afgesproken mbt dit soort toegang in de nieuwe LZ?

[marnixdessing]

Ik weet nou niet of we users aan mogen maken volgens de SCPs. Ik denk dat we daar hoe dan ook niet aan ontkomen, inderdaad voor automatische toegang zoals builds, containers pushen etc. Dus dat vereist het aanmaken van een user, wat mij betreft via CDK in het workload account zelf (dit hebben we vgm al wel eens besproken). Hiervoor moeten dan credentials aangemaakt worden en de user moet de juiste rechten krijgen om alleen naar die bucket te pushen. De user hoeft geen console toegang te hebben.

[joostvanderborg]

Thnx, dat was ook waar ik aan dacht. Ik zit ondertussen even te kijken naar wat documentatie. Github schrijft er dit over:

• https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services (hoe zorg je dat je met OIDC in AWS een rol kunt assumen, zónder een long lived access token in GH). Onderin een voorbeeld van feitelijk de workflow die we moeten hebben.
• https://github.com/aws-actions/configure-aws-credentials is dan wat je nodig hebt in de action geloof ik
• https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html dit moet aan AWS-kant geregeld worden.

Dan heb je als ik het goed begrijp:

• In AWS een oidc-Idp in de account waar het moet gebeuren
• In GH een client die daarmee kan connecten
• Een policy die bepaalt of GH een specifieke rol mag assumen (op basis van de aud en sub-claims in de id token)
• Een role die de s3-toegang voor GH regelt, waar die policy aan hangt?

Als we dat aan de praat krijgen is het geloof ik wel een nette oplossing. Misschien wat ingewikkelder bij eerste setup, maar wel netjes. Mogelijk moeten we eerst voor de simpele setup gaan (misschien zelfs een losse bucket in sandbox met een access token, zodat we niet tegen SCP-gedoe aanlopen voor Woweb aan de gang gaat), maar dit als oplossingsrichting bekijken?

[joostvanderborg]

Ik heb in de 'oude' sandbox-account een bucket + iam user met toegang + access key aangemaakt. In een klein cdk-projectje, dat zet ik nog ergens neer, of ik voeg dat samen met het bestaande infra-project wat ik dan ook in de oude sandbox uitrol.

In de nieuwe sandbox (in de nieuwe LZ dus) kan dit nog niet, daar lijken de SCP's inderdaad IAM-dingen tegen te houden. Morgen even bekijken.

[joostvanderborg]

Dit project is ook uitgerold in de 'oude' sandbox (de branch sandbox). Hier is de bucket extern beschikbaar via https://componenten-dev.sandbox.csp-nijmegen.nl

Er is in de sandbox-account een IAM user met een access key, die toegang heeft tot de bucket: De key staat in de secrets manager, met de access key id in de description.

[joostvanderborg]

@marnixdessing zie ook mail aan Woweb.