[JIRA] (JENKINS-61938) Can aws-secrets-manager-credentials-provider-plugin be configured to use a credential binding for authentication?
Title: Message Title Chris Kilding edited a comment on JENKINS-61938 Re: Can aws-secrets-manager-credentials-provider-plugin be configured to use a credential binding for authentication? I have looked at having the plugin depend on the AWS Global Configuration plugin, which allows an AWS key pair credential to be selected in the Jenkins UI.This would be the most appropriate place to get the AWS credential from, as the user would only have to specify it once for all their AWS-using plugins. Unfortunately it needs a good cleanup to make it more generic (I think it was extracted from the S3 plugin, and this shows), before I could use it as a dependency. Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.205818.1587074068000.13197.1587137760103%40Atlassian.JIRA.
[JIRA] (JENKINS-61938) Can aws-secrets-manager-credentials-provider-plugin be configured to use a credential binding for authentication?
Title: Message Title Chris Kilding commented on JENKINS-61938 Re: Can aws-secrets-manager-credentials-provider-plugin be configured to use a credential binding for authentication? I have looked at having the plugin depend on the AWS Global Configuration plugin, which allows an AWS key pair credential to be selected in the Jenkins UI. Unfortunately it needs a good cleanup to make it more generic (I think it was extracted from the S3 plugin, and this shows), before I could use it as a dependency. Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.205818.1587074068000.13195.1587137700123%40Atlassian.JIRA.
[JIRA] (JENKINS-61938) Can aws-secrets-manager-credentials-provider-plugin be configured to use a credential binding for authentication?
Title: Message Title Chris Kilding commented on JENKINS-61938 Re: Can aws-secrets-manager-credentials-provider-plugin be configured to use a credential binding for authentication? Hi red, The plugin is designed the way it is because most Jenkins installations will be in the same AWS account as their secrets, and because moving Jenkins further from the secrets imposes steep costs. It will be most secure if it authenticates using IAM instance profiles (EC2) or fine-grained service roles (EKS), and it will be most reliable if it can access Secrets Manager within Amazon's internal network, so both these things are encouraged. When Jenkins is run in a different cloud from Secrets Manager, the costs become apparent: Jenkins can't use IAM instance profiles, so you must provision an AWS access key pair for Jenkins, and then guard that key pair closely, because if it is stolen then the attacker can access every secret that Jenkins can access. Jenkins can't access Secrets Manager through Amazon's network, so its Secrets Manager connection is at the mercy of the public Internet. You can improve this somewhat by establishing an AWS PrivateLink between Jenkins and Secrets Manager, but it still won't be as good. No code in this plugin can solve the data locality problem, as it arises from your cloud architecture, and can only be properly addressed by altering your cloud architecture. So before going the multi-cloud route, consider if you can: Co-locate CJOC with the secrets (move CJOC to EC2 or EKS). Co-locate the secrets with CJOC (move the secrets that CJOC needs to Google Cloud; this will only work if CJOC is the only user of those secrets). If none of the above options work then you will need to use the "escape hatch" of passing the AWS key pair to the CJOC container through environment variables or system properties. Add Comment
[JIRA] (JENKINS-60764) Allow configuration per folder rather than globally
Title: Message Title Chris Kilding edited a comment on JENKINS-60764 Re: Allow configuration per folder rather than globally Regarding the question of access control... a new approach has just come up, which might be more appropriate for your use case.This approach would involve defining credentials for the folders plugin in JCasC YAML - basically what you have already done with the folders plugin, but codified in YAML. You would interpolate the actual values of those credentials using JCasC interpolation key syntax. The upcoming SecretSource support in the AWS secrets manager credentials provider (JENKINS-61291) would then resolve the values from Secrets Manager, and hand them back to JCasC, which would save them into the on-disk copy of those credentials.JCasC would then fetch the values from Secrets Manager consults its interpolation sources each time it runs, to keep them which should ensure that your credentials stay up to date on a frequency of however often you run JCasC .As far as your jobs are concerned, the credentials will still come from the folders plugin like they do today. So the folders plugin would still be responsible for access control. Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204025.1579015116000.6749.1583408160155%40Atlassian.JIRA.
[JIRA] (JENKINS-60764) Allow configuration per folder rather than globally
Title: Message Title Chris Kilding edited a comment on JENKINS-60764 Re: Allow configuration per folder rather than globally Regarding the question of access control... a new approach has just come up, which might be more appropriate for your use case.This approach would involve defining credentials for the folders plugin in JCasC YAML - basically what you have already done with the folders plugin, but codified in YAML. You would interpolate the actual values of those credentials using JCasC interpolation key syntax. The upcoming SecretSource support in the AWS secrets manager credentials provider (JENKINS-61291) would then resolve the values from Secrets Manager, and hand them back to JCasC, which would save them into the on-disk copy of those credentials. JCasC would then fetch the values from Secrets Manager each time it runs, to keep them up to date.As far as your jobs are concerned, the credentials will still come from the folders plugin like they do today. So the folders plugin would still be responsible for access control. Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204025.1579015116000.6746.1583408040201%40Atlassian.JIRA.
[JIRA] (JENKINS-60764) Allow configuration per folder rather than globally
Title: Message Title Chris Kilding commented on JENKINS-60764 Re: Allow configuration per folder rather than globally Regarding the question of access control... a new approach has just come up, which might be more appropriate for your use case. This approach would involve defining credentials for the folders plugin in JCasC YAML - basically what you have already done with the folders plugin, but codified in YAML. You would interpolate the actual values of those credentials using JCasC interpolation key syntax. The upcoming SecretSource support in the AWS secrets manager credentials provider (JENKINS-61291) would then resolve the values from Secrets Manager, and save them into the on-disk copy of those credentials. JCasC would then fetch the values from Secrets Manager each time it runs, to keep them up to date. As far as your jobs are concerned, the credentials will still come from the folders plugin like they do today. So the folders plugin would still be responsible for access control. Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204025.1579015116000.6743.1583407980164%40Atlassian.JIRA.
[JIRA] (JENKINS-60764) Allow configuration per folder rather than globally
Title: Message Title Chris Kilding commented on JENKINS-60764 Re: Allow configuration per folder rather than globally How secret names are treated is still up for discussion, at the moment the draft implementation rejects them, but we could potentially support a namespacing feature for this. Eg your Jenkins job would ask for credential ID "/" and it would be fetched from the relevant account. This would allow the secret names in each AWS account to be identical. But it leaks an implementation detail - the AWS account ID - into the Jenkins job definition, which is not ideal for credential portability. When I say Jenkins running in a shared tools account, basically this is a pattern where you have a number of environment-specific accounts (staging, prod) and you want a single Jenkins to manage them. It's not appropriate for that Jenkins to run in any of the environment-specific accounts, because by definition it exists outside those environments to manage them. As a result it is often put in an environment-independent account (sometimes called 'tools') with any other shared infrastructure (e.g. Artifactory), and given cross-account access to manage the relevant AWS resources in each environment. Even if a particular job only gets secrets from, say, the production account, under the hood Jenkins would make cross-account requests to get them. When you said you want to have a single Jenkins managing all three environments, I assumed you had a setup like this in mind. Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
[JIRA] (JENKINS-61291) Allow CasC to retrieve secrets from Secrets Manager
Title: Message Title Chris Kilding updated JENKINS-61291 Jenkins / JENKINS-61291 Allow CasC to retrieve secrets from Secrets Manager Change By: Chris Kilding Status: In Progress Review Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204868.1583151125000.6651.1583403420091%40Atlassian.JIRA.
[JIRA] (JENKINS-59670) Support retrieval of secrets from multiple AWS accounts
Title: Message Title Chris Kilding updated JENKINS-59670 Jenkins / JENKINS-59670 Support retrieval of secrets from multiple AWS accounts Change By: Chris Kilding Status: In Progress Review Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.202362.1570220885000.6648.1583403360603%40Atlassian.JIRA.
[JIRA] (JENKINS-60908) AWS Secrets Manager Plugin Breaking Change
Title: Message Title Chris Kilding updated JENKINS-60908 Jenkins / JENKINS-60908 AWS Secrets Manager Plugin Breaking Change Change By: Chris Kilding Status: In Progress Review Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204299.1580318008000.6650.1583403360625%40Atlassian.JIRA.
[JIRA] (JENKINS-60445) Depend on the AWS Global Configuration plugin
Title: Message Title Chris Kilding started work on JENKINS-60445 Change By: Chris Kilding Status: Open In Progress Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.203521.1576079821000.4706.1583318520077%40Atlassian.JIRA.
[JIRA] (JENKINS-60908) AWS Secrets Manager Plugin Breaking Change
Title: Message Title Chris Kilding started work on JENKINS-60908 Change By: Chris Kilding Status: Open In Progress Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204299.1580318008000.4701.1583318160200%40Atlassian.JIRA.
[JIRA] (JENKINS-61291) Allow CasC to retrieve secrets from Secrets Manager
Title: Message Title Chris Kilding commented on JENKINS-61291 Re: Allow CasC to retrieve secrets from Secrets Manager Implementation in PR #27 Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204868.1583151125000.3634.1583248800046%40Atlassian.JIRA.
[JIRA] (JENKINS-61291) Allow CasC to retrieve secrets from Secrets Manager
Title: Message Title Chris Kilding started work on JENKINS-61291 Change By: Chris Kilding Status: Open In Progress Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204868.1583151125000.3633.1583248740177%40Atlassian.JIRA.
[JIRA] (JENKINS-61291) Allow CasC to retrieve secrets from Secrets Manager
Title: Message Title Chris Kilding created an issue Jenkins / JENKINS-61291 Allow CasC to retrieve secrets from Secrets Manager Issue Type: Improvement Assignee: Chris Kilding Components: aws-secrets-manager-credentials-provider-plugin Created: 2020-03-02 12:12 Priority: Minor Reporter: Chris Kilding Most credentials in a CasC-configured Jenkins can be looked up through the CredentialsProvider API, but a handful of them cannot. These can only be supplied directly (hardcoding in the CasC YAML) or through CasC's lower-level SecretSource API. Implement the SecretSource API in this provider, to close the gap. Note: This feature is the counterpart to the configuration-as-code-secret-ssm-plugin, which does this with Parameter Store as the backend. Add Comment
[JIRA] (JENKINS-60401) Consider merging secret-ssm into aws-secrets-manager
Title: Message Title Chris Kilding commented on JENKINS-60401 Re: Consider merging secret-ssm into aws-secrets-manager I have written up the feature description in JENKINS-61291 Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.203456.1575893716000.2569.1583151180245%40Atlassian.JIRA.
[JIRA] (JENKINS-60764) Allow configuration per folder rather than globally
Title: Message Title Chris Kilding edited a comment on JENKINS-60764 Re: Allow configuration per folder rather than globally Closing in favour of a combination of JENKINS-60897 for authZ (add a notion of folders and credentials to the Jenkins access control plugins) .Additionally, don't forget and JENKINS-59670 for authN (support multi-account credentials lookup) which is a prerequisite to any of this work . [~rittneje] I'd appreciate your feedback on [GitHub PR #25|https://github.com/jenkinsci/aws-secrets-manager-credentials-provider-plugin/pull/25] to indicate if the cross-account feature design will work for your setup. Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204025.1579015116000.2535.1583149500142%40Atlassian.JIRA.
[JIRA] (JENKINS-60764) Allow configuration per folder rather than globally
Title: Message Title Chris Kilding updated JENKINS-60764 Closing in favour of JENKINS-60897 (add a notion of folders and credentials to the Jenkins access control plugins). Additionally, don't forget JENKINS-59670 (support multi-account credentials lookup) which is a prerequisite to any of this work. Jesse Rittner I'd appreciate your feedback on GitHub PR #25 to indicate if the feature design will work for your setup. Jenkins / JENKINS-60764 Allow configuration per folder rather than globally Change By: Chris Kilding Status: Open Fixed but Unreleased Resolution: Fixed Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)
[JIRA] (JENKINS-60764) Allow configuration per folder rather than globally
Title: Message Title Chris Kilding updated JENKINS-60764 Jenkins / JENKINS-60764 Allow configuration per folder rather than globally Change By: Chris Kilding Status: Fixed but Unreleased Closed Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204025.1579015116000.2533.1583149440517%40Atlassian.JIRA.
[JIRA] (JENKINS-60445) Depend on the AWS Global Configuration plugin
Title: Message Title Chris Kilding updated an issue Jenkins / JENKINS-60445 Depend on the AWS Global Configuration plugin Change By: Chris Kilding Comment: There are certain problems with leveraging this plugin.First, it has particular ideas about what kind of AWS auth strategy we will use, which may not be applicable in all cases. Eg Global Configuration expects you to use it with a single AWS account, but the credentials provider has an upcoming feature to let you specify a list of cross-account role ARNs which will allow it to retrieve credentials from the respective accounts. We couldn’t use the Global Configuration together with that feature, as the AWS auth strategy classes are different. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.203521.1576079821000.7042.1582720500069%40Atlassian.JIRA.
[JIRA] (JENKINS-60843) Support Secret File credential type
Title: Message Title Chris Kilding updated JENKINS-60843 Jenkins / JENKINS-60843 Support Secret File credential type Change By: Chris Kilding Status: In Review Resolved Resolution: Fixed Released As: 0.2.2 Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204201.1579778647000.4269.1582289700482%40Atlassian.JIRA.
[JIRA] (JENKINS-60843) Support Secret File credential type
Title: Message Title Chris Kilding updated JENKINS-60843 Jenkins / JENKINS-60843 Support Secret File credential type Change By: Chris Kilding Status: In Progress Review Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204201.1579778647000.4268.1582289700406%40Atlassian.JIRA.
[JIRA] (JENKINS-61111) Soft-deleted AWS Secrets Manager secrets still appear in Jenkins
Title: Message Title Chris Kilding updated JENKINS-6 In the absence of further information I'll have to assume that Ethan soft-deleted a secret and loaded the Jenkins credentials page within the 5-minute cache window. As mentioned, this is not something that can be fixed as long as we have to poll Secrets Manager for data. If, in the future, AWS allows Secrets Manager API clients to subscribe for updates on a push basis, then we could revisit this. Jenkins / JENKINS-6 Soft-deleted AWS Secrets Manager secrets still appear in Jenkins Change By: Chris Kilding Status: In Review Resolved Resolution: Won't Fix Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
[JIRA] (JENKINS-61111) Soft-deleted AWS Secrets Manager secrets still appear in Jenkins
Title: Message Title Chris Kilding edited a comment on JENKINS-6 Re: Soft-deleted AWS Secrets Manager secrets still appear in Jenkins The bit I missed was that the bug description does not say whether the deletion was recent i.e. within the 5 minute cache window.It is expected behaviour (indeed it is a tautology) that if a secret is deleted within the cache window, its entry will continue to be shown (though it will not be functional). It is indeed an idiosyncrasy in the user experience that we would rather not have, but it is unavoidable given the current polling strategy of integrating with Secrets Manager: there is no way for Jenkins to know that the secret is (soft-)deleted until it refreshes the cache and calls Secrets Manager again.When the time comes to refresh the cache, the ListSecretsOperation dutifully filters out soft-deleted secrets. This has been tested and is known to work. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204624.1581937282000.3534.1582202100177%40Atlassian.JIRA.
[JIRA] (JENKINS-61111) Soft-deleted AWS Secrets Manager secrets still appear in Jenkins
Title: Message Title Chris Kilding updated JENKINS-6 Jenkins / JENKINS-6 Soft-deleted AWS Secrets Manager secrets still appear in Jenkins Change By: Chris Kilding Status: In Progress Review Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204624.1581937282000.3536.1582202100257%40Atlassian.JIRA.
[JIRA] (JENKINS-61111) Soft-deleted AWS Secrets Manager secrets still appear in Jenkins
Title: Message Title Chris Kilding started work on JENKINS-6 Change By: Chris Kilding Status: Open In Progress Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204624.1581937282000.3535.1582202100234%40Atlassian.JIRA.
[JIRA] (JENKINS-61111) Soft-deleted AWS Secrets Manager secrets still appear in Jenkins
Title: Message Title Chris Kilding commented on JENKINS-6 Re: Soft-deleted AWS Secrets Manager secrets still appear in Jenkins The bit I missed was that the bug description does not say whether the deletion was recent i.e. within the 5 minute cache window. It is expected behaviour (indeed it is a tautology) that if a secret is deleted within the cache window, its entry will continue to be shown (though it will not be functional). It is indeed an idiosyncrasy in the user experience that we would rather not have, but it is unavoidable given the current polling strategy of integrating with Secrets Manager: there is no way for Jenkins to know that the secret is (soft-)deleted until it refreshes the cache and calls Secrets Manager again. When the time comes to refresh the cache, the ListSecretsOperation dutifully filters out soft-deleted secrets. This has been tested and is known to work. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204624.1581937282000.3533.1582201740045%40Atlassian.JIRA.
[JIRA] (JENKINS-61111) Soft-deleted AWS Secrets Manager secrets still appear in Jenkins
Title: Message Title Chris Kilding edited a comment on JENKINS-6 Re: Soft-deleted AWS Secrets Manager secrets still appear in Jenkins This is interesting because in theory we already have an integration test tests for this very scenario, which passes pass , demonstrating that it works - :* CredentialsProviderIT#shouldTolerateDeletedCredentials . * CredentialsProviderIT#shouldTolerateRecentlyDeletedCredentials If that’s correct then what Ethan saw was probably a one-off event. If not, something may be wrong in this test’s soft deletion logic. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204624.1581937282000.3529.1582200900054%40Atlassian.JIRA.
[JIRA] (JENKINS-60401) Consider merging secret-ssm into aws-secrets-manager
Title: Message Title Chris Kilding commented on JENKINS-60401 Re: Consider merging secret-ssm into aws-secrets-manager Since Secrets Manager is a distinct service from Parameter Store, they should probably continue to be handled by different plugins. However, it could make sense to add a Secrets Manager SecretSource implementation to this plugin, so that CasC can populate all secrets from Secrets Manager - not just the ones that can be referenced through the CredentialsProvider API. (I'm thinking of the bootstrapping secrets that CasC can't get from a CredentialsProvider.) This would be the counterpart of the Parameter Store SecretSource implementation in the ssm plugin. Thoughts? Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.203456.1575893716000.1455.1582023600232%40Atlassian.JIRA.
[JIRA] (JENKINS-60401) Consider merging secret-ssm into aws-secrets-manager
Title: Message Title Chris Kilding updated an issue Jenkins / JENKINS-60401 Consider merging secret-ssm into aws-secrets-manager Change By: Chris Kilding Comment: Hi Joseph, would this involving some specific logic to CasC so it knows to always read the credential provider config before doing secret resolution? Or could all of that be done in the (proposed) new secrets resolver? Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.203456.1575893716000.1451.1582023060171%40Atlassian.JIRA.
[JIRA] (JENKINS-60445) Depend on the AWS Global Configuration plugin
Title: Message Title Chris Kilding commented on JENKINS-60445 Re: Depend on the AWS Global Configuration plugin There are certain problems with leveraging this plugin. First, it has particular ideas about what kind of AWS auth strategy we will use, which may not be applicable in all cases. Eg Global Configuration expects you to use it with a single AWS account, but the credentials provider has an upcoming feature to let you specify a list of cross-account role ARNs which will allow it to retrieve credentials from the respective accounts. We couldn’t use the Global Configuration together with that feature, as the AWS auth strategy classes are different. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.203521.1576079821000.1187.1581962940051%40Atlassian.JIRA.
[JIRA] (JENKINS-61111) Soft-deleted AWS Secrets Manager secrets still appear in Jenkins
Title: Message Title Chris Kilding commented on JENKINS-6 Re: Soft-deleted AWS Secrets Manager secrets still appear in Jenkins This is interesting because in theory we already have an integration test for this very scenario, which passes, demonstrating that it works - CredentialsProviderIT#shouldTolerateDeletedCredentials. If that’s correct then what Ethan saw was probably a one-off event. If not, something may be wrong in this test’s soft deletion logic. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204624.1581937282000.1185.1581962220055%40Atlassian.JIRA.
[JIRA] (JENKINS-60897) JEP-225: Folders-based access control for any credentials provider
Title: Message Title Chris Kilding updated an issue Jenkins / JENKINS-60897 JEP-225: Folders-based access control for any credentials provider Change By: Chris Kilding Component/s: aws-secrets-manager-credentials-provider-plugin Component/s: kubernetes-credentials-provider-plugin Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204287.158023331.779.1581953340170%40Atlassian.JIRA.
[JIRA] (JENKINS-61112) Removing the jenkins:credentials:type tag from a secret does not make it disappear from Jenkins
Title: Message Title Chris Kilding updated an issue Jenkins / JENKINS-61112 Removing the jenkins:credentials:type tag from a secret does not make it disappear from Jenkins Change By: Chris Kilding Given I have a Secret Text credential stored in Secrets Manager (with the jenkins:credentials:type=string tag)When I remove the type tag, and wait for the credentials cache to reload,Then the Secret Text credential still remains in Jenkins. (It only disappears after I initiate a delete to remove the secret altogether, regardless of whether that tag was present or later removed.)If the type tag is removed, then the credential should disappear from Jenkins when the cache is reloaded . Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on t
[JIRA] (JENKINS-60908) AWS Secrets Manager Plugin Breaking Change
Title: Message Title Chris Kilding commented on JENKINS-60908 Re: AWS Secrets Manager Plugin Breaking Change Release Drafter doesn't go back in time to before it was enabled, so I have annotated the most recent tags with release notes manually. Ethan Stein could you look at the linked release notes, and indicate if they're clear enough about the breaking change in 0.2.0? (Or if not, what you'd modify - nothing else is dependent on these notes, so I can update them once or twice if needed.) https://github.com/jenkinsci/aws-secrets-manager-credentials-provider-plugin/releases#0.2.0 Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204299.1580318008000.543.1581939960215%40Atlassian.JIRA.
[JIRA] (JENKINS-60908) AWS Secrets Manager Plugin Breaking Change
Title: Message Title Chris Kilding commented on JENKINS-60908 Re: AWS Secrets Manager Plugin Breaking Change I've enabled Release Drafter on the repo, which will automatically write the changelog for each plugin release on the GitHub Releases page. This seems to be the best place to communicate changes in new versions, breaking or otherwise. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204299.1580318008000.541.1581938100112%40Atlassian.JIRA.
[JIRA] (JENKINS-60908) AWS Secrets Manager Plugin Breaking Change
Title: Message Title Chris Kilding commented on JENKINS-60908 Re: AWS Secrets Manager Plugin Breaking Change I've logged the problem with credentials sticking around after the jenkins:credentials:type tag is removed in JENKINS-61112 Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204299.1580318008000.539.1581937860107%40Atlassian.JIRA.
[JIRA] (JENKINS-61112) Removing the jenkins:credentials:type tag from a secret does not make it disappear from Jenkins
Title: Message Title Chris Kilding created an issue Jenkins / JENKINS-61112 Removing the jenkins:credentials:type tag from a secret does not make it disappear from Jenkins Issue Type: Bug Assignee: Chris Kilding Components: aws-secrets-manager-credentials-provider-plugin Created: 2020-02-17 11:09 Priority: Minor Reporter: Chris Kilding Given I have a Secret Text credential stored in Secrets Manager (with the jenkins:credentials:type=string tag) When I remove the type tag, and wait for the credentials cache to reload, Then the Secret Text credential still remains in Jenkins. (It only disappears after I initiate a delete to remove the secret altogether, regardless of whether that tag was present or later removed.) If the type tag is removed, then the credential should disappear from Jenkins. Add Comment
[JIRA] (JENKINS-61111) Soft-deleted AWS Secrets Manager secrets still appear in Jenkins
Title: Message Title Chris Kilding updated an issue Jenkins / JENKINS-6 Soft-deleted AWS Secrets Manager secrets still appear in Jenkins Change By: Chris Kilding Reported by [~esteinfama] Given I have an AWS secret that is being used as a Jenkins credential,When I soft-delete the secret (mark it as deleted) and it is still in its recovery window, Then the secret is still seen in Jenkins.Soft-deleted secrets should be hidden from Jenkins instead, as they are not intended to be used. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204624.1581937282000.536.1581937380253%40Atlassian.JIRA.
[JIRA] (JENKINS-60908) AWS Secrets Manager Plugin Breaking Change
Title: Message Title Chris Kilding commented on JENKINS-60908 Re: AWS Secrets Manager Plugin Breaking Change I've logged the soft-deleted secrets problem in JENKINS-6 Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204299.1580318008000.535.1581937380178%40Atlassian.JIRA.
[JIRA] (JENKINS-61111) Soft-deleted AWS Secrets Manager secrets still appear in Jenkins
Title: Message Title Chris Kilding created an issue Jenkins / JENKINS-6 Soft-deleted AWS Secrets Manager secrets still appear in Jenkins Issue Type: Bug Assignee: Chris Kilding Components: aws-secrets-manager-credentials-provider-plugin Created: 2020-02-17 11:01 Priority: Minor Reporter: Chris Kilding Given I have an AWS secret that is being used as a Jenkins credential, When I soft-delete the secret (mark it as deleted) and it is still in its recovery window, Then the secret is still seen in Jenkins. Soft-deleted secrets should be hidden from Jenkins instead, as they are not intended to be used. Add Comment
[JIRA] (JENKINS-60897) JEP-225: Folders-based access control for any credentials provider
Title: Message Title Chris Kilding updated an issue Jenkins / JENKINS-60897 JEP-225: Folders-based access control for any credentials provider Change By: Chris Kilding Summary: JEP-225: Allow folders plugin to work with Folders-based access control for any credentials provider Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204287.158023331.524.1581936780174%40Atlassian.JIRA.
[JIRA] (JENKINS-59670) Support retrieval of secrets from multiple AWS accounts
Title: Message Title Chris Kilding commented on JENKINS-59670 Re: Support retrieval of secrets from multiple AWS accounts Started work in GitHub PR #25 Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.202362.1570220885000.3966.1581091920051%40Atlassian.JIRA.
[JIRA] (JENKINS-59670) Support retrieval of secrets from multiple AWS accounts
Title: Message Title Chris Kilding started work on JENKINS-59670 Change By: Chris Kilding Status: Open In Progress Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.202362.1570220885000.3965.1581091860213%40Atlassian.JIRA.
[JIRA] (JENKINS-59670) Support retrieval of secrets from multiple AWS accounts
Title: Message Title Chris Kilding updated an issue Jenkins / JENKINS-59670 Support retrieval of secrets from multiple AWS accounts Change By: Chris Kilding The plugin should be able to retrieve secrets from multiple AWS accounts at the same time, and merge the results into one combined list of credentials.h2. Use case: Separate AWS accounts for deployment environments- I have a Jenkins in my environment-independent tools account.- I have dev secrets in my dev account.- I have production secrets in my production account.- And I want Jenkins to access secrets in the dev and production accounts. (I may also want to combine this with optional access control rules from JEP-225, to ensure that only the relevant jobs can see an environment's secrets. But that is another story.) Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails fr
[JIRA] (JENKINS-59670) Support retrieval of secrets from multiple AWS accounts
Title: Message Title Chris Kilding updated an issue Jenkins / JENKINS-59670 Support retrieval of secrets from multiple AWS accounts Change By: Chris Kilding The plugin should be able to retrieve secrets from multiple AWS accounts at the same time, and merge the results into one combined list of credentials. h2. Use case: Separate AWS accounts for deployment environments- I have a Jenkins in my environment-independent tools account.- I have dev secrets in my dev account.- I have production secrets in my production account.- And I want Jenkins to access secrets in the dev and production accounts. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.202362.15702208
[JIRA] (JENKINS-57577) Make credentials metadata caching duration user-configurable
Title: Message Title Chris Kilding started work on JENKINS-57577 Change By: Chris Kilding Status: Open In Progress Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.199492.1558430866000.1020.1580820060080%40Atlassian.JIRA.
[JIRA] (JENKINS-57577) Make credentials metadata caching duration user-configurable
Title: Message Title Chris Kilding commented on JENKINS-57577 Re: Make credentials metadata caching duration user-configurable Work begins in GitHub PR #24 Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.199492.1558430866000.1019.158082316%40Atlassian.JIRA.
[JIRA] (JENKINS-60764) Allow configuration per folder rather than globally
Title: Message Title Chris Kilding edited a comment on JENKINS-60764 Re: Allow configuration per folder rather than globally Since your environments are deployed as separate AWS accounts, but you've got only one (environment-independent) Jenkins, it sounds like your intended setup is that Jenkins will run in a shared AWS tools account (not dev, QA, or prod).The options I can see are something like the following: # Put the secrets for each environment in the tooling account. Use the JEP-225 folder-based credentials ACL to restrict jobs so they can only access the right credentials. # Store the secrets in their respective environment accounts. We implement JENKINS-59670 (cross-account secret retrieval) so the plugin can fetch secrets from multiple accounts. * You give Jenkins IAM cross-account roles * to let so it can call Secrets Manager in those accounts *(this is far preferable to supplying 3 access key pairs)*. Then use the JEP-225 folder-based credentials ACL as in solution 1.Option 2 is considerably more work, and also increases the number of HTTP requests (and therefore lag, and the possibility for network failures) to list secrets.But in both cases, the JEP-225 credentials ACL should do what you're asking for. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204025.1579015116000
[JIRA] (JENKINS-60897) JEP-225: Allow folders plugin to work with any credentials provider
Title: Message Title Chris Kilding updated an issue Jenkins / JENKINS-60897 JEP-225: Allow folders plugin to work with any credentials provider Change By: Chris Kilding Summary: JEP-225: Allow folders plugin to work with any credentials provider Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204287.158023331.69.1580744580179%40Atlassian.JIRA.
[JIRA] (JENKINS-60764) Allow configuration per folder rather than globally
Title: Message Title Chris Kilding commented on JENKINS-60764 Re: Allow configuration per folder rather than globally Since your environments are deployed as separate AWS accounts, but you've got only one (environment-independent) Jenkins, it sounds like your intended setup is that Jenkins will run in a shared AWS tools account (not dev, QA, or prod). The options I can see are something like the following: Put the secrets for each environment in the tooling account. Use the JEP-225 folder-based credentials ACL to restrict jobs so they can only access the right credentials. Store the secrets in their respective environment accounts. We implement JENKINS-59670 (cross-account secret retrieval) so the plugin can fetch secrets from multiple accounts. You give Jenkins IAM cross-account roles to let it call Secrets Manager in those accounts (this is far preferable to supplying 3 access key pairs). Then use the JEP-225 folder-based credentials ACL as in solution 1. Option 2 is considerably more work, and also increases the number of HTTP requests (and therefore lag, and the possibility for network failures) to list secrets. But in both cases, the JEP-225 credentials ACL should do what you're asking for. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and
[JIRA] (JENKINS-60897) Allow folders plugin to work with any credentials provider
Title: Message Title Chris Kilding commented on JENKINS-60897 Re: Allow folders plugin to work with any credentials provider JENKINS-58951 is to implement JCasC support for the folders plugin. This might need to be implemented before we can add the ACL on top. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204287.158023331.10778.1580735640150%40Atlassian.JIRA.
[JIRA] (JENKINS-58951) Add YAML Configurator for folders in JCasC
Title: Message Title Chris Kilding commented on JENKINS-58951 Re: Add YAML Configurator for folders in JCasC This is potentially a prerequisite for JEP-225 (folders-based ACL for any credentials provider), as we'd like to specify the ACL declaratively in YAML, probably somewhere on the folders plugin config. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.201298.1565877288000.10773.1580735520209%40Atlassian.JIRA.
[JIRA] (JENKINS-60902) Upgrade sshd-module to use SSHD 2.x
Title: Message Title Chris Kilding commented on JENKINS-60902 Re: Upgrade sshd-module to use SSHD 2.x Let’s say not an immediate urgency but perhaps a medium-term one... I get those errors in my plugin today, but fortunately only in tests: this is because the JGit SSH JUnit helper lib pulls in SSHD 2.2.0. It doesn’t affect my plugin in operation as I don’t need JGit in compile scope. But a plugin that does need a recent JGit version in compile scope would be affected today. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204292.1580299553000.9086.1580423280244%40Atlassian.JIRA.
[JIRA] (JENKINS-60897) Allow folders plugin to work with any credentials provider
Title: Message Title Chris Kilding updated an issue Jenkins / JENKINS-60897 Allow folders plugin to work with any credentials provider Change By: Chris Kilding Labels: JEP-225 Epic Name: JEP-225: Folders-based access control layer for any credentials provider Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204287.158023331.8863.1580387880290%40Atlassian.JIRA.
[JIRA] (JENKINS-60764) Allow configuration per folder rather than globally
Title: Message Title Chris Kilding commented on JENKINS-60764 Re: Allow configuration per folder rather than globally Could you let me know a bit more about your Jenkins setup? Is it On premises / hosted in AWS / hosted in another cloud provider? Are you using plain folders, or something else that's folder-like e.g. GitHub organization folders? Is this Jenkins for one team in your organization with 3 different deployment environments (dev, QA, prod)? Or do multiple teams use it? What other plugins do you use which interact with AWS services? Which credential providers are you using (apart from the folders plugin, and potentially the Secrets Manager one)? Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204025.1579015116000.8853.1580384640130%40Atlassian.JIRA.
[JIRA] (JENKINS-57577) Make credentials metadata caching duration user-configurable
Title: Message Title Chris Kilding commented on JENKINS-57577 Re: Make credentials metadata caching duration user-configurable Ethan Stein is interested this feature Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.199492.1558430866000.8851.1580384040057%40Atlassian.JIRA.
[JIRA] (JENKINS-60908) AWS Secrets Manager Plugin Breaking Change
Title: Message Title Chris Kilding commented on JENKINS-60908 Re: AWS Secrets Manager Plugin Breaking Change User-configurable cache duration has a ticket: JENKINS-57577. I'll note your interest there. The soft deletion of secrets is problematic in Moto (the AWS mock I use) because it doesn't have an effective notion of time (at least, not the kind of time frames we have in integration test lifecycles). This makes testing soft deletion very awkward and there could be a mistake there. I'll investigate. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204299.1580318008000.8850.1580383920145%40Atlassian.JIRA.
[JIRA] (JENKINS-60908) AWS Secrets Manager Plugin Breaking Change
Title: Message Title Chris Kilding commented on JENKINS-60908 Re: AWS Secrets Manager Plugin Breaking Change Hi Ethan, could you clarify the last sentence? Not quite sure what it means, but there might be something worth investigating in it. You are correct that it’s a breaking change. I kept the previous auto-detection strategy going as long as I could, but unfortunately the multi-type credential object this entailed broke fundamental assumptions of important credential consumers, like the Git plugin. So it was a tough call but I had to change it. I’ll add a doc notice as you suggest. The only in-band mechanism Jenkins currently provides to announce a breaking change is the plugin version number. However per the Semantic Versioning standard, this only really works if you are post version 1 (when you can indicate a breaking change with a major version increment). Therefore I intend to finish the last 2 or 3 minor changes I’m working on, sit on it for a while, then if all looks good release stable version 1.0.0. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204299.1580318008000.8392.1580319720136%40Atlassian.JIRA.
[JIRA] (JENKINS-60897) Allow folders plugin to work with any credentials provider
Title: Message Title Chris Kilding updated an issue Jenkins / JENKINS-60897 Allow folders plugin to work with any credentials provider Change By: Chris Kilding Component/s: aws-secrets-manager-credentials-provider-plugin Component/s: credentials-plugin Component/s: kubernetes-credentials-provider-plugin Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204287.158023331.8368.1580314500338%40Atlassian.JIRA.
[JIRA] (JENKINS-60897) Allow folders plugin to work with any credentials provider
Title: Message Title Chris Kilding updated an issue Jenkins / JENKINS-60897 Allow folders plugin to work with any credentials provider Change By: Chris Kilding Today the folders plugin provides an access control layer over its own local credentials provider. This works, but it means that if a user wants to restrict access to a particular credential by folder, they cannot store it in their preferred provider: instead they must copy it into the FolderCredentialsProvider.I would like to extend the plugin so that it can provide its access control layer (ACL) over *any* credentials provider.h2. Benefits * *Only write the access control logic once.* Today, other providers would have to copy-paste the intricate ACL logic from the folders plugin, and then keep that up to date with any changes. Mistakes will inevitably be made. * *It works the same way everywhere.* Folders-based ACL will not have provider-specific behaviour, or a provider-specific storage schema for the ACL. * *ACL can be written in JCasC YAML.* Each folder entry just needs to have a list of allowed credential IDs. * *Single Responsibility Principle.* Providers do one thing: store and retrieve credentials. Folders plugin does one thing (for credentials): run the ACL over the providers.h2. Tasks TODO convert these to sub-tasks * Design JCasC YAML schema for the ACL * Design Web UI for the ACL * Decide on default behaviour when folders plugin is present, a job accesses a credential, but no restrictions are configured for that credential: ** Default allow? (Treat it as a global credential) ** Default deny? (Don't ask, don't get) * Make ACL work with other folder types (GitHub/Bitbucket Organization Folders) * Deprecate/remove legacy bits of CredentialsProvider / CredentialsStore API that were meant to be used for access control (since it would not be their job any more) * Ensure ease of use with infrastructure tools like Terraform (it should be as simple as possible to have Terraform define Secrets Manager secrets, then interpolate the relevant IDs into the JCasC YAML). Add Comment
[JIRA] (JENKINS-60897) Allow folders plugin to work with any credentials provider
Title: Message Title Chris Kilding updated an issue Jenkins / JENKINS-60897 Allow folders plugin to work with any credentials provider Change By: Chris Kilding Issue Type: Improvement Epic Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204287.158023331.8316.1580309700667%40Atlassian.JIRA.
[JIRA] (JENKINS-60902) Upgrade sshd-module to use SSHD 2.x
Title: Message Title Chris Kilding created an issue Jenkins / JENKINS-60902 Upgrade sshd-module to use SSHD 2.x Issue Type: Improvement Assignee: Unassigned Components: core Created: 2020-01-29 12:05 Priority: Minor Reporter: Chris Kilding Some of the libraries that Jenkins uses (e.g. JGit) have moved on to use SSHD 2.x. This contains breaking changes. But sshd-module still expects SSHD 1.x. The incompatibilities cause either compile-time or runtime 'class not found' errors in Jenkins and its plugins. We need to bump our SSHD dependencies to fix this. Options: SSHD 2.2.0 (also used by the current release of JGit) SSHD 2.3.0 (the very latest version) Affected downstream components: Gerrit Trigger plugin git-server plugin Jenkins Core CLI Remote terminal access plugin ...
[JIRA] (JENKINS-60764) Allow configuration per folder rather than globally
Title: Message Title Chris Kilding commented on JENKINS-60764 Re: Allow configuration per folder rather than globally I believe the JENKINS-60897 proposal can do what you ultimately are trying to achieve (having some credentials restricted to jobs in folder A, some restricted to jobs in folder B, some restricted to jobs in folders A and B, and some global credentials with no folder restrictions). But there is a fundamental constraint in the way: a plugin has only one instance in Jenkins. You couldn't run multiple instances of a plugin (e.g. to apply different configurations) on the same Jenkins server. So under the proposal, you'd achieve it like this instead: Install credential provider plugin. Install folders plugin. Configure the credentials access control layer (ACL) on the folders plugin. Example: If I have 4 secrets in Secrets Manager that I want to use in Jenkins like this: foo (visible to jobs in folders A and B) bar (visible to jobs in folder A) baz (visible to jobs in folder B) qux (global, visible to all jobs) I would configure the ACL like this in JCasC (I suppose you could also use Job DSL or the GUI): folders: a: someUnrelatedProperty: 'hello' credentials: - 'foo' - 'bar' b: someUnrelatedProperty: 'world' credentials: - 'foo' - 'baz' (The implication in this particular design is that if you access a credential like qux which has no folder restrictions, it is treated as global.) Does that sound like what you're after? Add Comment
[JIRA] (JENKINS-60764) Allow configuration per folder rather than globally
Title: Message Title Chris Kilding edited a comment on JENKINS-60764 Re: Allow configuration per folder rather than globally Have written up I have started writing an epic for the work that would need to be done on the folders - plugin in JENKINS-60897. [~rittneje] Could you take a look and comment with the kind of functionality you'd like to see? Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204025.1579015116000.7469.1580235060379%40Atlassian.JIRA.
[JIRA] (JENKINS-60897) Allow folders plugin to work with any credentials provider
Title: Message Title Chris Kilding updated an issue Jenkins / JENKINS-60897 Allow folders plugin to work with any credentials provider Change By: Chris Kilding Today the folders plugin provides an access control layer over its own local credentials provider. This works, but it means that if a user wants to restrict access to a particular credential by folder, they cannot store it in their preferred provider: instead they must copy it into the FolderCredentialsProvider.I would like to extend the plugin so that it can provide its access control layer (ACL) over *any* credentials provider.h2. Benefits * *Only write the access control logic once.* Today, other providers would have to copy-paste the intricate ACL logic from the folders plugin, and then keep that up to date with any changes. Mistakes will inevitably be made. * *It works the same way everywhere.* Folders-based ACL will not have provider-specific behaviour, or a provider-specific storage schema for the ACL. * *ACL can be written in JCasC YAML.* Each folder entry just needs to have a list of allowed credential IDs. * *Single Responsibility Principle.* Providers do one thing: store and retrieve credentials. Folders plugin does one thing (for credentials): run the ACL over the providers.h2. Questions Tasks * Design JCasC YAML schema for the ACL * Default credential access Design Web UI for the ACL * Decide on default behaviour when folders plugin is present, a job accesses a credential, but no credential restrictions are configured for that credential: ** Default allow? (Treat it as a global credential) ** Default deny? (Don't ask, don't get) * Making Make ACL work with other folder types (GitHub/Bitbucket Organization Folders) * Deprecate/remove legacy bits of CredentialsProvider / CredentialsStore API that were meant to be used for access control (since it would not be their job any more) * Ensure ease of use with infrastructure tools like Terraform (it should be as simple as possible to have Terraform define Secrets Manager secrets, then interpolate the relevant IDs into the JCasC YAML). Add Comment
[JIRA] (JENKINS-60897) Allow folders plugin to work with any credentials provider
Title: Message Title Chris Kilding updated an issue Jenkins / JENKINS-60897 Allow folders plugin to work with any credentials provider Change By: Chris Kilding Today the folders plugin provides an access control layer over its own local credentials provider. This works, but it means that if a user wants to restrict access to a particular credential by folder, they cannot store it in their preferred provider: instead they must copy it into the FolderCredentialsProvider.I would like to extend the plugin so that it can provide its access control layer (ACL) over *any* credentials provider. h2. Benefits The benefits of this include: * *Only write the access control logic once.* Today, other providers would have to copy-paste the intricate ACL logic from the folders plugin, and then keep that up to date with any changes. Mistakes will inevitably be made. * *It works the same way everywhere.* Folders-based ACL will not have provider-specific behaviour, or a provider-specific storage schema for the ACL. * *ACL can be written in JCasC YAML.* Each folder entry just needs to have a list of allowed credential IDs. * *Single Responsibility Principle.* Providers do one thing: store and retrieve credentials. Folders plugin does one thing (for credentials): run the ACL over the providers. h2. Questions * JCasC YAML schema for the ACL * Default credential access behaviour when folders plugin is present, but no credential restrictions are configured for that credential: ** Default allow? (Treat it as a global credential) ** Default deny? (Don't ask, don't get) * Making ACL work with other folder types (GitHub/Bitbucket Organization Folders) Add Comment
[JIRA] (JENKINS-60764) Allow configuration per folder rather than globally
Title: Message Title Chris Kilding edited a comment on JENKINS-60764 Re: Allow configuration per folder rather than globally Have written up the work that would need to be done on the folders plugin in this issue JENKINS-60897 . Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204025.1579015116000.7455.1580233500360%40Atlassian.JIRA.
[JIRA] (JENKINS-60764) Allow configuration per folder rather than globally
Title: Message Title Chris Kilding commented on JENKINS-60764 Re: Allow configuration per folder rather than globally Have written up the work that would need to be done on the folders plugin in this issue. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204025.1579015116000.7453.1580233500328%40Atlassian.JIRA.
[JIRA] (JENKINS-60897) Allow folders plugin to work with any credentials provider
Title: Message Title Chris Kilding created an issue Jenkins / JENKINS-60897 Allow folders plugin to work with any credentials provider Issue Type: Improvement Assignee: Chris Kilding Components: cloudbees-folder-plugin Created: 2020-01-28 17:41 Priority: Minor Reporter: Chris Kilding Today the folders plugin provides an access control layer over its own local credentials provider. This works, but it means that if a user wants to restrict access to a particular credential by folder, they cannot store it in their preferred provider: instead they must copy it into the FolderCredentialsProvider. I would like to extend the plugin so that it can provide its access control layer (ACL) over any credentials provider. The benefits of this include: Only write the access control logic once. Today, other providers would have to copy-paste the intricate ACL logic from the folders plugin, and then keep that up to date with any changes. Mistakes will inevitably be made. It works the same way everywhere. Folders-based ACL will not have provider-specific behaviour, or a provider-specific storage schema for the ACL. ACL can be written in JCasC YAML. Each folder entry just needs to have a list of allowed credential IDs. Single Responsibility Principle. Providers do one thing: store and retrieve credentials. Folders plugin does one thing (for credentials): run the ACL over the providers.
[JIRA] (JENKINS-59626) Global configuration page blocks may try to load credentials before credentials providers are ready
Title: Message Title Chris Kilding commented on JENKINS-59626 Re: Global configuration page blocks may try to load credentials before credentials providers are ready The fallback was to return a non-cached empty list. (Emphasis on the non-cached bit - to avoid an error blocking the plugin from trying again in the next N minutes.) I implemented this in my provider and the credentials UI views no longer break when there is service degradation behind the scenes. However the user still does not know that there was a communication error with the backing store, unless they look in the Jenkins logs. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.202270.1570028542000.6889.1580150040170%40Atlassian.JIRA.
[JIRA] (JENKINS-60879) Depend on the Jenkins BOM
Title: Message Title Chris Kilding started work on JENKINS-60879 Change By: Chris Kilding Status: Open In Progress Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204265.1580144908000.6884.1580149500083%40Atlassian.JIRA.
[JIRA] (JENKINS-60692) credential type icon not correctly reflected
Title: Message Title Chris Kilding updated JENKINS-60692 Jenkins / JENKINS-60692 credential type icon not correctly reflected Change By: Chris Kilding Status: In Review Resolved Resolution: Fixed Released As: 0.2.1 Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.203937.1578489951000.6877.1580148000607%40Atlassian.JIRA.
[JIRA] (JENKINS-60692) credential type icon not correctly reflected
Title: Message Title Chris Kilding updated JENKINS-60692 Jenkins / JENKINS-60692 credential type icon not correctly reflected Change By: Chris Kilding Status: In Progress Review Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.203937.1578489951000.6875.1580148000425%40Atlassian.JIRA.
[JIRA] (JENKINS-60880) PCT not working for icon-shim plugin
Title: Message Title
Chris Kilding updated an issue
Jenkins / JENKINS-60880
PCT not working for icon-shim plugin
Change By:
Chris Kilding
I am proposing a change to the Jenkins BOM which will add pipeline-model-definition plugin. This necessarily pulls in the icon-shim plugin.The Jenkins BOM build fails on a PCT step that tests the icon-shim plugin, when it tries to check it out from source. The message is:{noformat}error: pathspec 'icon-shim-1.0.3' did not match any file(s) known to git{noformat} The long version:{noformat}Starting plugin tests on core coordinates : MavenCoordinates[groupId=org.jenkins-ci.plugins, artifactId=plugin, version=2.176.3]Starting plugin tests on core coordinates : MavenCoordinates[groupId=org.jenkins-ci.plugins, artifactId=plugin, version=2.176.3]Plugin ace-editor not in included plugins => test skipped !...Plugin git-server not in included plugins => test skipped !Jan 27, 2020 4:45:35 PM org.jenkins.tools.test.model.PluginRemoting retrievePomDataINFO: org.jenkins-ci.plugins.icon-shim icon-shim-pom 1.0.3 ../ Jan 27, 2020 4:45:35 PM org.jenkins.tools.test.PluginCompatTester testPluginsINFO: Detected parent POM: org.jenkins-ci.plugins.icon-shim:icon-shim-pom:1.0.3## Starting to test plugin icon-shim v1.0.3## against MavenCoordinates[groupId=org.jenkins-ci.plugins, artifactId=plugin, version=2.176.3]Processing org.jenkins.tools.test.hook.BlueOceanHookHook not triggered. Continuing.Processing org.jenkins.tools.test.hook.SwarmHookHook not triggered. Continuing.Processing org.jenkins.tools.test.hook.DeclarativePipelineHookHook not triggered. Continuing.Processing org.jenkins.tools.test.hook.StructsHookHook not triggered. Continuing.Processing org.jenkins.tools.test.hook.PipelineRestApiHookHook not triggered. Continuing.Processing org.jenkins.tools.test.hook.ConfigurationAsCodeHookHook not triggered. Continuing.Created plugin checkout dir : /home/jenkins/workspace/Tools_bom_PR-179/pct-work/icon-shimPOM did not provide an SCM tag. Inferring tag 'icon-shim-1.0.3'.Checking out from SCM connection URL : scm:git:git://github.com/jenkinsci/icon-shim-plugin.git (icon-shim-1.0.3) at tag icon-shim-1.0.3[INFO] Executing: /bin/sh -c cd '/home/jenkins/workspace/Tools_bom_PR-179/pct-work' && 'git' 'clone' 'git://github.com/jenkinsci/icon-shim-plugin.git' '/home/jenkins/workspace/Tools_bom_PR-179/pct-work/icon-shim'[INFO] Working directory: /home/jenkins/workspace/Tools_bom_PR-179/pct-work[INFO] Executing: /bin/sh -c cd '/home/jenkins/workspace/Tools_bom_PR-179/pct-work/icon-shim' && 'git' 'fetch' 'git://github.com/jenkinsci/icon-shim-plugin.git'[INFO] Working directory: /home/jenkins/workspace/Tools_bom_PR-179/pct-work/icon-shim[INFO] Executing: /bin/sh -c cd '/home/jenkins/workspace/Tools_bom_PR-179/pct-work/icon-shim' && 'git' 'checkout' 'icon-shim-1.0.3'[INFO] Working directory: /
[JIRA] (JENKINS-60880) PCT not working for icon-shim plugin
Title: Message Title Chris Kilding updated an issue Jenkins / JENKINS-60880 PCT not working for icon-shim plugin Change By: Chris Kilding Attachment: build log.txt Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204266.1580146049000.6871.1580146260147%40Atlassian.JIRA.
[JIRA] (JENKINS-60880) PCT not working for icon-shim plugin
Title: Message Title Chris Kilding created an issue Jenkins / JENKINS-60880 PCT not working for icon-shim plugin Issue Type: Improvement Assignee: Tom FENNELLY Components: icon-shim-plugin, plugin-compat-tester Created: 2020-01-27 17:27 Environment: ci.jenkins.io Jenkins 2.176.3 Priority: Minor Reporter: Chris Kilding I am proposing a change to the Jenkins BOM which will add pipeline-model-definition plugin. This necessarily pulls in the icon-shim plugin. The Jenkins BOM build fails on a PCT step that tests the icon-shim plugin, when it tries to check it out from source. The message is: error: pathspec 'icon-shim-1.0.3' did not match any file(s) known to git The long version: Starting plugin tests on core coordinates : MavenCoordinates[groupId=org.jenkins-ci.plugins, artifactId=plugin, version=2.176.3]Starting plugin tests on core coordinates : MavenCoordinates[groupId=org.jenkins-ci.plugins, artifactId=plugin, version=2.176.3]Plugin ace-editor not in included plugins => test skipped !...Plugin git-server not in included plugins => test skipped !Jan 27, 2020 4:45:35 PM org.jenkins.tools.test.model.PluginRemoting retrievePomDataINFO: org.jenkins-ci.plugins.icon-shim icon-shim-pom 1.0.3 ../ Jan 27, 2020 4:45:35 PM org.jenkins.tools.test.PluginCompatTester testPluginsINFO: Det
[JIRA] (JENKINS-60880) PCT not working for icon-shim plugin
Title: Message Title Chris Kilding updated an issue Jenkins / JENKINS-60880 PCT not working for icon-shim plugin Change By: Chris Kilding Issue Type: Improvement Bug Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204266.1580146049000.6869.1580146080457%40Atlassian.JIRA.
[JIRA] (JENKINS-60879) Depend on the Jenkins BOM
Title: Message Title Chris Kilding created an issue Jenkins / JENKINS-60879 Depend on the Jenkins BOM Issue Type: Improvement Assignee: Chris Kilding Components: aws-secrets-manager-credentials-provider-plugin Created: 2020-01-27 17:08 Priority: Minor Reporter: Chris Kilding Use on the Jenkins BOM to resolve plugins and core dependencies. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
[JIRA] (JENKINS-60843) Support Secret File credential type
Title: Message Title Chris Kilding started work on JENKINS-60843 Change By: Chris Kilding Status: Open In Progress Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204201.1579778647000.5300.1579889460105%40Atlassian.JIRA.
[JIRA] (JENKINS-60843) Support Secret File credential type
Title: Message Title Chris Kilding commented on JENKINS-60843 Re: Support Secret File credential type Work begins in GitHub PR #22 Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204201.1579778647000.5301.1579889460162%40Atlassian.JIRA.
[JIRA] (JENKINS-60692) credential type icon not correctly reflected
Title: Message Title Chris Kilding commented on JENKINS-60692 Re: credential type icon not correctly reflected This fix will be included in the next plugin release. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.203937.1578489951000.4966.1579868280103%40Atlassian.JIRA.
[JIRA] (JENKINS-60692) credential type icon not correctly reflected
Title: Message Title Chris Kilding commented on JENKINS-60692 Re: credential type icon not correctly reflected Progress on JENKINS-60766 will take some time, so in the meantime the best option was to use the icon class names (and therefore leverage the icons provided by the upstream credentials jars), and to add conformance tests that will fail if the upstream jars ever change their icon class names. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.203937.1578489951000.4964.1579868220173%40Atlassian.JIRA.
[JIRA] (JENKINS-60695) "Filter by AWS secret namespace ID" not working
Title: Message Title Chris Kilding updated JENKINS-60695 Jenkins / JENKINS-60695 "Filter by AWS secret namespace ID" not working Change By: Chris Kilding Status: In Review Resolved Resolution: Fixed Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.203940.1578490848000.4870.1579861260579%40Atlassian.JIRA.
[JIRA] (JENKINS-60695) "Filter by AWS secret namespace ID" not working
Title: Message Title Chris Kilding updated JENKINS-60695 Jenkins / JENKINS-60695 "Filter by AWS secret namespace ID" not working Change By: Chris Kilding Status: In Progress Review Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.203940.1578490848000.4868.1579861260532%40Atlassian.JIRA.
[JIRA] (JENKINS-60695) "Filter by AWS secret namespace ID" not working
Title: Message Title Chris Kilding commented on JENKINS-60695 Re: "Filter by AWS secret namespace ID" not working Started work in GitHub PR #20 Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.203940.1578490848000.4242.1579781160269%40Atlassian.JIRA.
[JIRA] (JENKINS-60695) "Filter by AWS secret namespace ID" not working
Title: Message Title Chris Kilding started work on JENKINS-60695 Change By: Chris Kilding Status: Open In Progress Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.203940.1578490848000.4240.1579781100168%40Atlassian.JIRA.
[JIRA] (JENKINS-60692) credential type icon not correctly reflected
Title: Message Title Chris Kilding commented on JENKINS-60692 Re: credential type icon not correctly reflected Started work in GitHub PR #19 Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.203937.1578489951000.4238.1579780320257%40Atlassian.JIRA.
[JIRA] (JENKINS-60692) credential type icon not correctly reflected
Title: Message Title Chris Kilding started work on JENKINS-60692 Change By: Chris Kilding Status: Open In Progress Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.203937.1578489951000.4236.1579780260187%40Atlassian.JIRA.
[JIRA] (JENKINS-60843) Support Secret File credential type
Title: Message Title Chris Kilding created an issue Jenkins / JENKINS-60843 Support Secret File credential type Issue Type: Improvement Assignee: Chris Kilding Components: aws-secrets-manager-credentials-provider-plugin Created: 2020-01-23 11:24 Priority: Minor Reporter: Chris Kilding Support the 'Secret File' credential type in the provider. Hat tip to Peter Fich who suggested this. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
[JIRA] (JENKINS-60329) Username/password credentials can not be used with git
Title: Message Title Chris Kilding updated JENKINS-60329 Jenkins / JENKINS-60329 Username/password credentials can not be used with git Change By: Chris Kilding Status: In Review Resolved Resolution: Fixed Released As: 0.2.0 Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.203338.1575027217000.4206.1579778580248%40Atlassian.JIRA.
[JIRA] (JENKINS-60820) Use JGit SSH Git server in integration tests
Title: Message Title Chris Kilding updated JENKINS-60820 Implemented in master Jenkins / JENKINS-60820 Use JGit SSH Git server in integration tests Change By: Chris Kilding Status: In Review Resolved Resolution: Fixed Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenk
[JIRA] (JENKINS-60820) Use JGit SSH Git server in integration tests
Title: Message Title Chris Kilding updated JENKINS-60820 Jenkins / JENKINS-60820 Use JGit SSH Git server in integration tests Change By: Chris Kilding Status: In Progress Review Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204161.1579517934000.2960.1579548540217%40Atlassian.JIRA.
[JIRA] (JENKINS-60820) Use JGit SSH Git server in integration tests
Title: Message Title Chris Kilding started work on JENKINS-60820 Change By: Chris Kilding Status: Open In Progress Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204161.1579517934000.2959.1579548540144%40Atlassian.JIRA.
[JIRA] (JENKINS-60791) Plugin can break other providers' credential bindings when it cannot contact AWS
Title: Message Title Chris Kilding updated JENKINS-60791 Jenkins / JENKINS-60791 Plugin can break other providers' credential bindings when it cannot contact AWS Change By: Chris Kilding Status: In Review Resolved Resolution: Fixed Released As: 0.1.3 Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204119.1579175394000.2933.1579537740259%40Atlassian.JIRA.
[JIRA] (JENKINS-60791) Plugin can break other providers' credential bindings when it cannot contact AWS
Title: Message Title Chris Kilding updated JENKINS-60791 Jenkins / JENKINS-60791 Plugin can break other providers' credential bindings when it cannot contact AWS Change By: Chris Kilding Status: In Progress Review Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204119.1579175394000.2932.1579537680316%40Atlassian.JIRA.
[JIRA] (JENKINS-60652) Plugin breaks credential list views when it cannot contact AWS
Title: Message Title Chris Kilding updated JENKINS-60652 Jenkins / JENKINS-60652 Plugin breaks credential list views when it cannot contact AWS Change By: Chris Kilding Status: In Review Resolved Resolution: Fixed Released As: 0.1.3 Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.203894.157833410.2931.1579537680303%40Atlassian.JIRA.
[JIRA] (JENKINS-60652) Plugin breaks credential list views when it cannot contact AWS
Title: Message Title Chris Kilding updated JENKINS-60652 Jenkins / JENKINS-60652 Plugin breaks credential list views when it cannot contact AWS Change By: Chris Kilding Status: In Progress Review Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.203894.157833410.2929.1579537620231%40Atlassian.JIRA.
[JIRA] (JENKINS-60764) Allow configuration per folder rather than globally
Title: Message Title Chris Kilding commented on JENKINS-60764 Re: Allow configuration per folder rather than globally I believe we are looking at some wider design changes like the following: The folders plugin stores and manages the ACL matrix (an association of credentials to folders). JCasC support to let the folders plugin read its ACL matrix from CasC YAML. FolderCredentialsProvider is either removed, or becomes a simple filtering proxy for other credential providers. (Optional) Remove ACL-related parameters like itemGroup from the CredentialsProvider getCredentials API. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.204025.1579015116000.2717.1579526340136%40Atlassian.JIRA.
[JIRA] (JENKINS-60764) Allow configuration per folder rather than globally
Title: Message Title Chris Kilding edited a comment on JENKINS-60764 Re: Allow configuration per folder rather than globally There is a way to do it within the constraints of the current design, but it's not good.AbstractFolder is public, and we do have access to the itemGroup in our own providers, so we could potentially do the same test on the itemGroup / walk up the tree, get the folder name, check that against something we can store in our credentials provider, and return a scoped list, and otherwise return the unscoped global credentials.This is bad because: * We would have to duplicate large amounts of folders plugin logic (and tests) in every credentials provider that wanted to support folder-scoped credentials. (Possibility for bugs to creep in, behaviour updates applied erratically across all providers etc.) * We would be overloading credentials providers with responsibilities they shouldn't have. A provider should really have 1 purpose - store and retrieve a list of credentials - because this is already complex enough, especially with the retry/failure handling for remote providers. * We would need the provider's data store to hold extra ACL metadata, which could make its storage schema more complicated, or could be a poor fit for some data stores. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/je
