---
# System prepended metadata

title: Untitled

---

**Why's**

1. Why was the secret check-in to GitHub?
    - Developer was working on two threads together - DB2 and FFUI. DB2 connector doesn't runs on local machine so developer was using one of the test machines
    - For generting docker image, developed obtained `ffbld01` artifactory API key, and have stored temporarily inside `DB2` source code in commented format. 
    - After docker image was generated, developer forgot to remove the artifactory key from DB2 source code and as detect-secrets was not configured on test machine, the secret was not detected during `GIT commit`
2. Why was the secrete in the directory?
    - Secret was needed to create & push docker image with a custom branch which is not possible with standard Jenkin job.
3. Why the developers key did not have relevant permission?
    - Developers' ID usually do not have push permission to the artifactory. 
4. Why is there no job to push the non connector component with a custom branch?
    - There is one such job available [here](https://appcon-jenkins.swg-devops.com/job/BuildDockerImageForNonConnectorComponents/build?delay=0sec), but it's not known to many developers
    - Ideally, this ability should be part of standard Jenkin's component job.
5. Why is the ffbld01 key easily accessible?
    - It is by design.
    - responsibility is left to individual squad/developers to keep the build ie: sandbox up to date that required the ffbld01 key to pull the images
    - No automated process to update the API key's in the builds.

**Steps followed to resolve the issue**
1. We followed the steps given in the playbook [here](https://github.ibm.com/Cloud-Integration/appconnect-wiki/wiki/Handle-leaked-ffbld01-artifactory-API-key)
2. All the pipelines were recovered and working fine after following the steps in the playbook but after about 5 days on 17th March morning suddenly all the pipelines started throwing 403 errors again.
3. We tried double-checking everything but this time we did not find any place where the old key was being used.
4. So as an alternate solution, @simon-holdsworth suggested us to use another id firefly.dev.funct03@uk.ibm.com and replace this new ID everywhere with its new key
5. As suggested we have added this ID and its key in all iPaaS pipelines which seems to have solved the problem of failing iPass pipelines.


**Possible solution to avoid future problems**
1. We can provide namespace-based image pushing permission ability to individual users so the user will never require the ffdid key?
2. We can make provision to push images from the custom branch to any testing namespace directly from default Jenkin's job of the component.
4. We can think of a design to have different keys for different pipelines to avoid a single point of failure.
5. We can think of having the possibility of using two ffdids like id1 and id2 and by default, only Id1 will be used but if for some reason key1 is leaked, users can pass any Boolean parameter for running the builds with id2 until key1 is revoked and regenerated so it won't impact the running operation.
6. Avoid test machines to for committing source code to GIT