4 ms·

So exactly how would you suggest using a YubiKey in a script that runs automatically and is meant to run unsupervised? Wouldn’t it be logical that Google knew

So exactly how would you suggest using a YubiKey in a script that runs automatically and is meant to run unsupervised? Wouldn’t it be logical that Google knew about zero trust? The problem wasn’t the API Key, the problem was that the poster didn’t use best practices - see my other comment. Even if it wasn’t a built in facility like the three or four ways to authenticate with GCP or AWS programmatically and you did have to use long live API keys, you could still piggy back off the cloud providers access I mentioned and read from a secure cloud hosted vault using your temporary keys from your script. In the case of AWS read your third party API key from secrets manager and read secret manager based on your keys in your home directory or better yet your short lived local keys in your environment variables - not a local environment file that you will probably forget to use .gitignore for

giveita 1y ago
Ideally an unauthorised script e.g. CI/CD is authenticated via a session initially. Yes under the hood a secret is stored and you could argue its morally an API key - however the UX wouldnt be developer logs in, copies a key to their clipboard then pastes it hopefully in the CI secrets section but also likely in the code.
- scarface_74 1y ago
  I know more about AWS, but GCP from what I read is similar, best practice is that you have a web page that you authenticate to via SSO and get temporary access keys that you assign to environment variables. The SDK automatically knows how to read from the environment variables locally. When you run your code on the cloud platform, you attach privileges to the run time environment (VM, Lambda, docker runtime, etc) that are properly scoped for least privilege. The SDK also knows how to get your permissions from it automatically. You never need to worry about your code getting the proper access keys. I’ve done most of my CI/CD using AWS native services that you also attach the role to the runtime. For instance CodeBuild is really just a Linux or Windows Docker runtime that you can run anything in and you attach permissions to your CodeBuild project. Of course your AWS access is controlled ideally via your SSO or 2FA. I have done some work with Azure DevOps - which doesn’t have anything to do with Azure. You can also use it to deploy your AWS and you store your access keys in an Azure controlled vault and your pipeline gives AWS permissions to your scripts. I think the same thing works with GitHub Actions.

giveita 1y ago

Ideally an unauthorised script e.g. CI/CD is authenticated via a session initially. Yes under the hood a secret is stored and you could argue its morally an API key - however the UX wouldnt be developer logs in, copies a key to their clipboard then pastes it hopefully in the CI secrets section but also likely in the code.

scarface_74 1y ago
I know more about AWS, but GCP from what I read is similar, best practice is that you have a web page that you authenticate to via SSO and get temporary access keys that you assign to environment variables. The SDK automatically knows how to read from the environment variables locally. When you run your code on the cloud platform, you attach privileges to the run time environment (VM, Lambda, docker runtime, etc) that are properly scoped for least privilege. The SDK also knows how to get your permissions from it automatically. You never need to worry about your code getting the proper access keys. I’ve done most of my CI/CD using AWS native services that you also attach the role to the runtime. For instance CodeBuild is really just a Linux or Windows Docker runtime that you can run anything in and you attach permissions to your CodeBuild project. Of course your AWS access is controlled ideally via your SSO or 2FA. I have done some work with Azure DevOps - which doesn’t have anything to do with Azure. You can also use it to deploy your AWS and you store your access keys in an Azure controlled vault and your pipeline gives AWS permissions to your scripts. I think the same thing works with GitHub Actions.