1412039 - Spin up Jenkins slave with instance profile containing a read only policy

Status: RESOLVED WONTFIX

(Cloud Services :: Operations: Miscellaneous, task)

Description

[Greg G]

For bug 1378405, secops wants to run jobs from jenkinsv2 with read only access to AWS configs and needs AWS API keys for the dev, stage, and prod accounts.


I believe this can be done as follows for each account:

go to the IAM Management Console page

create a new user with programmatic / API access but not console access and the  ReadOnlyAccess managed policy (I don't have permission to do this)

create an API key for that user?

add the creds to hiera-sops and the jenkins secret store?

profit?

If those are the right steps then I can generate the creds myself if someone gives me temporary create user permission too.

Comment 1

[Jeremy Orem [:oremj]]

Usually we add Jenkins secrets to the secrets store. Since this is just read only access, a set of credentials is probably fine. Alternatively, I can spin a new slave, for this, with an instance profile containing a read only policy.

Comment 2

[Greg G]

(In reply to Jeremy Orem [:oremj] from comment #1)
> Usually we add Jenkins secrets to the secrets store. Since this is just read
> only access, a set of credentials is probably fine. Alternatively, I can
> spin a new slave, for this, with an instance profile containing a read only
> policy.

Yeah, the secrets don't need to be in hiera-sops. A set of credentials in the security credentials store sounds good.

Comment 3

[Chris Kolosiwsky [:ckolos] (ckolos has left the building)]

I think the slave + policy is the better option over managing creds.

Comment 4

[Greg G]

(In reply to Chris Kolosiwsky [:ckolos] from comment #3)
> I think the slave + policy is the better option over managing creds.

+1 wfm


For context, the initial goal is to run daily baseline style jobs and eventually:

* test other accounts like data and web-eng
* run aws-config lambdas to alert on high confidence and high severity issues
* possibly run as a deploy step against new resources

Comment 5

[Chris Kolosiwsky [:ckolos] (ckolos has left the building)]

Not sure about running the lambda's in a context other than an "actual" account, but the other two are def. possible with a role.

Comment 6

[Greg G]

(In reply to Chris Kolosiwsky [:ckolos] from comment #5)
> Not sure about running the lambda's in a context other than an "actual"
> account, but the other two are def. possible with a role.

A role sounds good.


We don't have any lambdas to deploy and they'll likely need additional permissions to send notifications anyway (write SNS, SES, or SQS).

Comment 7

[Greg G]

(In reply to Jeremy Orem [:oremj] from comment #1)
> Alternatively, I can spin a new slave, for this, with an instance profile containing a read only policy.

OK so we want to go this route.


:oremj can you let me know when you get a chance to do this?

Comment 8

[Greg G]

Chatted with :oremj on irc.


This would require one slave per account which would be painful and prevent running cross account tests, so I'm going to close this and go with his recommendation to assume a limited role at the beginning of the jenkins job.