From cac67326b4e5a8e4b495b24178cef1b3d6d64afe Mon Sep 17 00:00:00 2001 From: saifeddine Rajhi Date: Sat, 20 Jan 2024 21:20:59 +0100 Subject: [PATCH] fix typos --- README.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index c22bcb9f..85231094 100644 --- a/README.md +++ b/README.md @@ -21,10 +21,10 @@ Azure is the newest with AWS having the most supported resources Feel free to submit PR or Issue if you find an issue or even better add new resources, and then I'll take a look at merging it ASAP. -**CAVEAT** The outputs of this tool are your first step, if you have AWS your can now generate resources partially, there are no conditions and even partial resources are wildcarded (for now) +**CAVEAT** The outputs of this tool are your first step, if you have AWS, you can now generate resources partially, there are no conditions and even partial resources are wildcarded (for now). (for AWS) -**best practice** would go further (and I am working on it as well), you need will to modify these permissions to the minimum required in your enviornment by adding these -restrictions, you can also deploy using short lived credentials (usinmg this tool or Vault) (in AWS so far), generatING short-lived credentials for your build +**best practice** would go further (and I am working on it as well), you will need to modify these permissions to the minimum required in your enviornment by adding these +restrictions, you can also deploy using short lived credentials (using this tool or Vault) (in AWS so far), generating short-lived credentials for your build and then remotely (REMOTE) supply and invoke your builds (INVOKE). Ideally I would like to do this for you, but these policies are currently determined statically (QUICKER), and unrecorded intentions can be impossible to infer.