Todd, i think you are right, I can't get around it - I need to pass something from my live environment (where it's kept encrypted) into my image.
I can however potentially simplify the setup by passing a single key that I can use to unlock a PasswordVault in my image and it can have multiple values which I can then use for my different api keys. When creating my image, I can encode those values in a less hostile environment and pass them through like I do now, where they get stored in the PasswordVault. This seems pretty simple now I talk it through. Thanks to everyone for additional ideas - it's useful to know it's not a simple X thing that I've missed. Tim Sent from my iPhone > On 16 Aug 2017, at 19:41, Todd Blanchard <[email protected]> wrote: > > I do a lot of deployments on AWS elastic beanstalks. > > I put the credentials into environment variables on the beanstalk. > > When running locally, the credentials are in the environment on my machine. > >> On Aug 16, 2017, at 9:55 AM, Tim Mackinnon <[email protected]> wrote: >> >> Hi - I’m struggling to find something that I saw that discussed this issue >> kind of. >> >> In my image (its actually a headless one - but this could apply to a fat >> image too) - I build an application that needs access to a service (in this >> case an S3 bucket). >> >> The AWS library I’m using (but others are similar) has an AWSLogin class >> singleton where I can specify a username and password. So in a playground I >> can do that and test it all works etc. >> >> However, for deployment its never a good idea to encode this info into your >> code (particularly if you use Iceberg and GitHub) - SO, I am using secret >> variable support in GitLab - which I’ve seen many projects do in other >> languages. This way, I type in those details into an encrypted place in the >> CI and it then exposes them as temporary variables when I build my system >> (so far so good). >> >> Now in my build - I run a little script like this and pass on those >> variables (neatly, Gitlab doesn’t show their values in its logs): >> >> ./pharo Pharo.image --no-default-preferences --save --quit st config.st \ >> "{‘$USER'. ‘$PWD'}" >> >> In config.st I then extract these command line parameters (the ST handler >> nicely exposes the extra parameter array so I didn’t have to do anything >> custom) >> >> "Expect image to be called with params as a last arg array" >> config := Array readFrom: Smalltalk arguments last. >> user := config at: 1. >> pwd := config at: 2. >> >> DBConfig default >> accessKey: user; >> pKey: pwd; >> yourself. >> So it all looks pretty good so far - however it occurs to me that if you get >> hold of a .image and were to browse all of the Strings - e.g. >> ./pharo Pharo.image eval "(ByteString allInstances)” >> I think you would ulimtately find those strings unless the Class encrypts >> them in some way right? >> So I’m wondering why we don’t have an EncryptedString object for just this >> (I’ve seen lots of cryptography libraries etc), but isn’t this quite a >> common thing to deal with? And should Pharo provide something that library >> writers adopt to encourage better image safety? Or am I wrong in my analysis? >> >> Tim >> >
