ok something extremely weird is happening and may ...
# getting-started
ok something extremely weird is happening and may be a bug. need some help please! I am creating an NS record for a Route53 TLD housed in another account, like so:
Copy code
const nsRecord = new aws.route53.Record(pre('dns-record'), rootZoneId.apply(rootZoneId => { return {
		zoneId: rootZoneId,
		name: `${subDomainName}.${tldName}`,
		type: "NS",
		ttl: 86400,
		records: subDomainZone.nameServers,
	}}) as unknown as aws.route53.RecordArgs, { provider: sharedAccountProvider })
The DNS record is actually created, but Pulumi shows:
Copy code
* creating urn:pulumi:REDACTED: 1 error occurred:
        * waiting for Route 53 Record (REDACTED) create: AccessDenied: User: REDACTED/core-infra-cross-acc-session is not authorized to perform: route53:GetChange on resource: arn:aws:route53:::change/REDACTED because no identity-based policy allows the route53:GetChange action
        status code: 403, request id: 86b4b8f0-5e7a-445d-a012-3c689e063dbf
Even stranger, if I delete that record manually, pulumi refresh, and attempt to re-create it.... it is recreated successfully but pulumi shows the same error. This appears to be reproducible.
I would check if whatever AWS identity you are using has permission to perform the
action in the account where you are creating the records.
yup, i enabled all Route53 permissions
i thought i was missing one
I suspect a different AWS permission is missing
going to re-test this with omni permissions (can do everything)
ok... something weird's going on
all permissions are allowed, still seeing same error
Couple of things to check: • Is that enabled on all resources or have you locked it down (as you should) with a resource ARN? • If you did lock it down, make sure the ARN allows for that action to be performed on the ARN mentioned in the error message.
it says:
Copy code
no identity-based policy allows the route53:GetChang
but the policy is "*" and used to be "route53:*"
i have it locked down to one resource arn
could it be looking at a diff route53 resource to confirm? like, not the hosted zone?
I don't know but I would start by comparing the ARN in the error message and the resource ARN in your policy.
oh what the f**k
Copy code
GetChange on resource: arn:aws:route53:::change/C07579521RPEJQVAFENQO
Perhaps time to read about the GetChange action and see what that ARN is about. It looks specific to Route53 records.
yeah... time to self-educate. sorry about the false alarm and derping by not reading logs
All good. It happens! Glad to see you start with a question on how to do something with Pulumi and then doing it. Good luck with the rest! :)
yup! succeeded with my least access of:
Copy code
const allowedTargetArns = [

const allowedActions = [
ARN format is specific to
yeah? If so, you could move that to a separate policy statement instead of clubbing it with other actions. Unless, it needs to apply to all other R53 actions too?
you are right, but will lock things down a bit later 🙂 still in the prototyping process. okay maybe I am sleep deprived or something but this seems really weird. here are my role principals for that allow policy:
Copy code
"Principal": {
                "AWS": [
now ... when I do "aws sts get-caller-identity", they both match. But when I'm logged into the prodAdmin user and select stack "production", I get:
Copy code
pulumi:providers:aws (core-infra-cross-acc):
    error: rpc error: code = Unknown desc = 2 errors occurred:
        * unable to validate AWS credentials.
    Details: [{0xc0016ca000 0xc0037432f0}]
    Make sure you have set your AWS region, e.g. `pulumi config set aws:region us-west-2`
Which is related to this:
Copy code
const sharedAccountProvider = new aws.Provider(pre('cross-acc'), {
    assumeRole: sharedRoleArn.apply(roleArn => {
		console.dir(`roleARN ${roleArn}`)
		return {
			roleArn: roleArn,
			sessionName: pre('cross-acc-session')}
This code works on the staging stack/acc but not prod stack/acc. Does pulumi have any special protections or treatments for stacks named "production" ?
I have confirmed that both stacks are attempting to assume the same role
nvm... aws config was mangled in a way where "aws sts get-caller-identity" worked but not all other commands did. fml