PR-6175 SBX stack deployment

[reweeden]

The naming convention is a little different from our ASF forks as we use dev instead of sbx.

[mattp0]

I think we should set this up with a separate vault and api key as more than ASF I&A will be capable of running this CI pipeline. Or we need to consider how we restrict access of running this.

[mattp0]

We probably have to do both. I have concerns about people deploying to an ASF NGAP account that are outside ASF security bounds. Access to deploy resources to our accounts need to be governed through NAMS imo.

[mattp0]

I think separate VAULT, separate AWS access keys is something we should do for sure and we should ensure repo settings are setup correctly for the actions.

[reweeden]

What would be the justification for setting up a separate vault? It still needs to have deploy keys for the same account and those keys will have the same exact scope. That seems to me to accomplish nothing security wise but add an extra maintenance burden on us to rotate an extra set of keys every 60 days.

As for who can trigger the workflow:

1. You can't configure much when it comes to permissions for running workflows. As far as I can tell that is bound to who has write permission on the repo. As it's currently set up the only way to trigger the workflow is through the workflow_dispatch (requires write permissions) or by pushing a branch (also requires write permissions). Since the workflow doesn't run on PR's that's not a concern.
2. There's not going to be a way to tie NAMS into this. GitHub actions permissions are controlled by GitHub, end of story. ASF is admin on the repo, so ASF can control who has those permissions and outside collaborators don't need them in most cases.

[mattp0]

Separate vault because now the people who have access to this repo can not get all the secrets from our 1password vault and there are maintainers that are not on I&A.

The only purpose for separate keys is that we can track who deployed things. To me its about being able to trace who used the keys. I just want clear separation of the keys used by this public community project from the ones used by ASF I&A. Yes it is additional maintenance but it is risk management.

Right but the access to this NGAP account is governed by NAMS. So we have a responsibility to take care with these access keys and not let un-authorized people have access is the only reason I am bring NAMS up here. I am just saying we need to ensure these controls are in place before this is released is all. Your response that the controls are based on write access is sufficient.

[reweeden]

Does a separate vault come with a separate OnePassword connector token? That's really what we need to actually separate those things out.

Does AWS even have the feature to track how a resource was deployed? When I've needed that information in the past I haven't been able to find it.

[mattp0]

When I was shared the token I was told this was I&A's specific token. So I would think so but not 100% positive.

I think you can see when accounts were last accessed. but not positive about when keys were used last. Might be something we cant do anything about. Besides manage the list of people that can access to write to this repo?

[lindsleycj]

Just curious is ASF using this repo directly? It was my understanding that this repo was just a template for all DAACs. You would clone it to something like CIRRUS-ASF the very first time you started using CIRRUS and then you would put all your daac specific stuff in your own repo. NSIDC and ORNL have their own DAAC repos.

[reweeden]

Yea we have our own CIRRUS-ASF repo, but we're trying to set up a CI for this so we can test changes that we make to this template repo.