search

Azure / azure-dev

A developer CLI that reduces the time it takes for you to get started on Azure. The Azure Developer CLI (azd) provides a set of developer-friendly commands that map to key stages in your workflow - code, build, deploy, monitor, repeat.
https://aka.ms/azd
MIT License
386 stars 178 forks source link

[Issue] azd pipeline config uses GitHub repository variables instead of secrets #3586

Open christiannagel opened 4 months ago

christiannagel commented 4 months ago

Running azd pipeline config adds these values as repository variables:

Only AZD_INITIAL_ENVIRONMENT_CONFIG is configured as a repository secret.

This documentation https://learn.microsoft.com/en-us/azure/developer/github/connect-from-azure?tabs=azure-portal%2Clinux#create-github-secrets specifies to define these as secrets:

I think, these should be defined as secrets, and this workflow adapted: https://github.com/Azure-Samples/azd-starter-bicep/blob/main/.github/workflows/azure-dev.yml

In case these values are no longer treated as secrets and can be accessed publicly, as it would be against secretless federated authentication, it should be documented that secrets are not required here, but given the option to use secrets e.g. with azd pipeline config parameters. Specified by the learn documentation from the above link: Saving the values as GitHub secrets is the more secure option.

azd version 1.7.0 (commit 49d6adc2efb178083f61822e6b4715258560803d) aspire 8.0.0-preview.5.24170.4/8.0.100 SDK 8.0.200

rajeshkamal5050 commented 3 months ago

@vhvb1989 please take a look and pull it into milestones, if need be.

vhvb1989 commented 3 months ago

We use to have secrets only, but eventually changed this to variables. We did the change specially to prevent github setting a mask (**) on top the outputs we wanted to show (the azd gives you the link to the Azure Portal, for example, which includes the SubscriptionId).

I think we could move tenant and clientid to be secrets again, but I would like to do some researching about it. The concept of github variables has not been there forever (like secrets have). I wonder if the docs are just targeting secrets as a default way to ingest the gh-action, but not as a mandatory.

We have test recordings and presentations (videos) to folks which have been recorded showing client ids, sub id and tenant id. The tenant id is also visible during Interactive-login to EntraId (from the url), so I don't think it is considered a real secret (like something that needs to be rotated if ever leaked).

christiannagel commented 3 months ago

Before creating this issue, I did some research on it - if I'm right with my thoughts, or if this might have changed in the last years. Here is some information that can help with your decision @vhvb1989:

With public repos, variables are publicly visible with the GitHub actions log, while secrets are not. Are these values really secrets? I use recordings with client ids, sub ids, and tenant ids as well - but not with ids from production environments. I'm deleting client ids from tests.

Some information I found:

While they are not sensitive on their own, they can be used in combination with other information to potentially gain unauthorized access to resources. Therefore, it’s a good practice to keep them confidential and follow the principle of least privilege. Always ensure that they are securely stored and not exposed in your code or logged in a non-secure manner. If you need to share them, use secure methods like Azure Key Vault or similar secure storage solutions. Remember, security is about layers, and every piece of information that is kept confidential adds another layer of protection.

And this, which is important for some organizations - with one of my clients I'm supporting them to fulfill the requirements from their organization, and this is one:

Do note that some companies and privacy reviews often consider these 3 data points as Organization Identifiable Information (OII) and sometimes have policies for handling those (less stringent that PII though).

https://stackoverflow.com/questions/45661109/are-azure-subscription-id-aad-tenant-id-and-aad-app-client-id-considered-secre https://learn.microsoft.com/en-us/answers/questions/340725/is-subscription-id-personal-or-should-be-kept-priv

rudiv commented 3 months ago

Just came here to raise the exact same issue as there was only 1 secret created despite expecting all 6 in the Secrets tab.

This definitely seems wrong, even if variables are new, they're not secrets and it doesn't seem right that everyone should have access to these on the team in a repository. Whether they can be used or not on their own, they're still identifiable information.