https://pulumi.com logo
Join Slack
Powered by
Hey guys, opening this to a little discussion, wha...
# aws
m
Hey guys, opening this to a little discussion, what are some of the tradeoffs that you consider when deciding to create a Pulumi-backed IAM Policy Document via ONE of the following mechanisms: 1. Invoking aws.iam.getPolicyDocument (function approach) 2. Assigning a variable of type aws.iam.PolicyDocument (interface approach) 3. JSON.stringify approach e.g. (raw approach, inline or file, etc.)
Copy code
import * as pulumi from "@pulumi/pulumi";
import * as aws from "@pulumi/aws";

const policy = new aws.iam.Policy("policy", {
    name: "test_policy",
    path: "/",
    description: "My test policy",
    policy: JSON.stringify({
        Version: "2012-10-17",
        Statement: [{
            Action: ["ec2:Describe*"],
            Effect: "Allow",
            Resource: "*",
        }],
    }),
});
I'm also interested on how you guys are approach authoring them too, so if you have any unique practices, I'm interested to see!
👀 1
m
I prefer `pulumi.jsonStringify` (or the equivalent `pulumi.Output.json_dumps` in Python) because it allows me to write the IAM policy documents in their original format while adding in Pulumi output values where I need them.
m
Ah, that's a fairly interesting approach. I just took a look at how the other two mechanisms would be employed in Python, and, in that case I'd likely choose that approach as well. It seems like there isn't as much bang for your buck when actually authoring it cus tl;dr dynamic typing + you end typing just about the same amount of characters anyways. Am I correct in this assessment?
Typescript let's me do some neat things working w/ interfaces, so the general pattern I follow is declaring and exporting per property (e.g. a list of actions assigned to a variable)
m
I can't speak to other languages, but with Python I feel that using 
get_policy_document
doesn't really save much typing or screen space. I do read and write AWS IAM policies outside of Pulumi as well, so having everything in a complete, familiar format is nice. Plus copy-&-pasting between the AWS console, policy documents, and Pulumi code is easiest this way.
I think that with the new TypedDict input types my assessment might change but I haven't had the chance to try this in the wild yet
m
Copy code
const S3_READ_ACTIONS = ['s3:GetObject', 's3:ListBucket'] as const;
const S3_WRITE_ACTIONS = ['s3:PutObject', 's3:DeleteObject'] as const;
you can do cheeky things like this.
I author and maintain an internal library my org uses to write the Pulumi proggies that ultimately get ran by the engine.
so encapsulating things for semantics sake is a design pattern I try to maximize on.
👍 1
m
> you can do cheeky things like this. This is possible in Python as well, unless I'm missing something here? You're creating blocks of (arrays of) strings and then assemble the policy out of that?
m
I'm sure it is but from a cursory glance, it wouldn't be too "pythonic" I suppose. Haven't written a python library in awhile so I could be wrong on that.
I'm actually assembling GetPolicyDocumentStatementArgs, I export something like the above, and assign that to the properties of the GetPolicyDocumentStatementArgs I am assembling.
Oops I mean GetPolicyDocumentStatement lol
GetPolicyDocumentStatementArgs is (a bit confusingly) the output analog to GetPolicyStatement (which is also confusingly the name of the type/interface representing a IAM Policy Document statement)
its 5am gn.
m
I don't think that's necessarily "unpythonic" to create such a system of building blocks.
A pattern which I've found to be very convenient for standard permissions management is AWS CDK's "grants". Not sure if someone has tried to replicate this in Pulumi yet, but being able to say 
bucket.grant_read(role)
is very neat.
m
this.grants(that)
is quite powerful. Lmao, ahh CDK makes me very jealous at times, but then I think about the Cloudformation underneath... lol. Seems like you just gave me an interesting case for a first pull request!
30 Views
Open in Slack
PreviousNext
Powered by