kubernetes-management
kubernetes-management copied to clipboard
jenkins-infra
Configure SystemRead on weekly.ci
Is this safe to enable? Given weekly.ci is a show-off instance, with a public configuration, I'd assume there's nothing sensitive extended read would expose, would it?
Is this safe to enable? Given weekly.ci is a show-off instance, with a public configuration, I'd assume there's nothing sensitive extended read would expose, would it?
Credentials at least (I guess there is a GH App credential at least).
Ping @daniel-beck @Wadeck @timja @MarkEWaite @jglick can i still your knowledge to help us answer Alex's question here?
As an OPS, I have a bit of reluctance but maybe that it me being too paranoid.
Additionnaly: setting the whole system in full tmpfs (instead of persistence) with a daily reset could leverage risks (and avoid any future manual changes in the UI without putting it as code)
The point of system read is that nothing sensitive should be exposed assuming plugins are being sensible I doubt there’s anything that would be bad but would need to check it (it’s down atm)
The point of system read is that nothing sensitive should be exposed assuming plugins are being sensible I doubt there’s anything that would be bad but would need to check it (it’s down atm)
https://weekly.ci.jenkins.io/ is down for you? (I can see it)
The point of system read is that nothing sensitive should be exposed assuming plugins are being sensible I doubt there’s anything that would be bad but would need to check it (it’s down atm)
weekly.ci.jenkins.io is down for you? (I can see it)
You can see it now, it was down at the time I checked
Thanks for your message @timja : it allowed us to see that weekly.ci.jenkins.io was restarting regularly due to its helm release failing to deploy changes in #3991 (rollbacked in #3996). It should be stable now: can you confirm?
(cc @NotMyFault )
I checked https://weekly.ci.jenkins.io/manage/configuration-as-code/
the only two interesting values I saw are the ldap configuration and the github app for weekly.
It looks fine to me but up to you all.
I checked https://weekly.ci.jenkins.io/manage/configuration-as-code/
the only two interesting values I saw are the ldap configuration and the github app for weekly.
It looks fine to me but up to you all.
The LDAP password should not be available at all (even encrypted) in an ideal world. Is this mandatory to use the LDAP for authentication on this instance (vs. the default security realm with password encrypted in the helm chart)?
For the GH app, it's up to you @timja as I believe it's only for jenkinsci GH organization: is that correct?
Is this mandatory to use the LDAP for authentication on this instance (vs. the default security realm with password encrypted in the helm chart)?
I think it's fine without ldap
For the GH app, it's up to you @timja as I believe it's only for jenkinsci GH organization: is that correct?
it is yes, tbh not sure if it even needs a github app, but fine for it as-is
Is this mandatory to use the LDAP for authentication on this instance (vs. the default security realm with password encrypted in the helm chart)?
I think it's fine without ldap
For the GH app, it's up to you @timja as I believe it's only for jenkinsci GH organization: is that correct?
it is yes, tbh not sure if it even needs a github app, but fine for it as-is
Thanks for confirming. I propose (cc @NotMyFault ) that we update weekly.ci.jenkins.io setup to ensure we can use the System read safely:
- Switch from LDAP to "local jenkins user database"
- Remove the usage of GitHub app credential
Is this mandatory to use the LDAP for authentication on this instance (vs. the default security realm with password encrypted in the helm chart)?
I think it's fine without ldap
For the GH app, it's up to you @timja as I believe it's only for jenkinsci GH organization: is that correct?
it is yes, tbh not sure if it even needs a github app, but fine for it as-is
Thanks for confirming. I propose (cc @NotMyFault ) that we update weekly.ci.jenkins.io setup to ensure we can use the System read safely:
- Switch from LDAP to "local jenkins user database"
- Remove the usage of GitHub app credential
Works for me 👍
From his message, I assume that Jesse was not aware of https://weekly.ci.jenkins.io/, as it was refered to "weekly.ci" only.
From what I can see the https://weekly.ci.jenkins.io/manage/credentials/store/system/domain/_/credential/github-app-weekly/ credentials could be removed as it's used only for https://github.com/jenkins-infra/kubernetes-management/blob/d4fbff8e4fc6754c37355d6f1a6b0d40b0761a8b/config/jenkins_weekly.ci.jenkins.io.yaml#L102-L103, which is a public repository. I don't want to receive security reports on such stuff asking for a bounty :)
(💡 same thing with https://github.com/jenkins-infra/kubernetes-management/blob/d4fbff8e4fc6754c37355d6f1a6b0d40b0761a8b/config/jenkins_infra.ci.jenkins.io.yaml#L423-L424 for the infra instance)
💡 I don't know if the configuration of "pipeline-library" is for the demo purpose, it's not used. None of the pipeline is using shared libraries.
No concerns from my side 👍
credentials could be removed
Rate limiting can be an issue, but no real danger in app credentials that can read a single repo (or even all public repos in the org), which is how they should be configured.
