Support for role in AWS? about registry-creds HOT 12 CLOSED

I see it's not supported now that i've had time to dig in. Will you accept a patch to fix / add functionality? Are there any blockers that I should know about before I sink a bunch of time into it?

from registry-creds.

Hey @luck02 not sure what you are wanting to do? Use a Role to auth to ECR? I'm ok to take a PR, but just want to understand your use case better.

from registry-creds.

Use a role ARN + secrets to generate the token. In this case the credentials don't have access on ECR, but the role we'd assume does.

so given:

[default]
region = us-east-1
output = json

[profile example]
role_arn = arn:aws:iam::999999999:role/role-arn-23423423etc
source_profile = default

in the CLI we'd do:

aws ec2 describe-instances --profile example

Presumably we can use stscreds to assume a given role: http://docs.aws.amazon.com/sdk-for-go/api/aws/credentials/stscreds/

Then we can just add that to the ECR part of the secret.yaml (and obviously pick that up in main.go). At that stage I think it's just checking to see if there's an sts ARN specified and creating credentials and then passing them to the ECR get login.

I think that's it at any rate.

from registry-creds.

Are you wanting to use this for a cluster running in AWS? Or off cloud? I'm not aware of a way to assume a role off cloud without specific creds to get you the STS token.

from registry-creds.

My use case ATM is minikube. You'd still need to provide credentials, but you'd also provide a role ARN.

from registry-creds.

So your secrets data section would look like this:

apiVersion: v1
kind: Secret
metadata:
  name: registry-creds-ecr
  namespace: kube-system
  labels:
    app: registry-creds
    kubernetes.io/minikube-addons: registry-creds
    cloud: ecr
data:
  AWS_ACCESS_KEY_ID: Y2hhbmdlbWU=
  AWS_SECRET_ACCESS_KEY: Y2hhbmdlbWU=
  aws-account: Y2hhbmdlbWU=
  aws-region: dXMtZWFzdC0x
  aws-assume-role: YXJuOmF3czppYW06Ojk5OTk5OTk5OTpyb2xlL3JvbGUtYXJuLTIzNDIzNDIzZXRj
type: Opaque

That's all bunk data of course.

But you'd need aws-account, account-id, access-key, region. aws-assume-role would be 'optional' and could be blank. if it's blank then use credentials the way it does now. If it's not blank then assume the role and use that to get your token.

Does that make more sense?

from registry-creds.

Yup that makes sense now. Feel free to send over a PR if you'd like this, then I can package up and update MInikube upstream.

from registry-creds.

It's been awhile since I wrote go code (v1.5ish since I was full time). The dep landscape has moved around. What tool are you using to manage dependencies? I don't see it in the readme.md file, if it's there apologies :|

from registry-creds.

Just an FYI, I was thinking the best way to test the controller was with a mock, but I think it's easy enough to just follow your pattern. I'm still curious about the vendor / dep tooling though. I think we were using godeps a couple years back.

from registry-creds.

PR: #51

from registry-creds.

Right now I'm using govendor to vendor my deps to the vendor directory. I've been poking around with dep and glide some, but just havn't decided if another is better for my needs.

from registry-creds.

Closed with #51

from registry-creds.