Closed gitlabbin closed 5 years ago
Fix in release >= 3.2.2
Unfortunately its not as simple as that. The source user must have admin or teamdev_user role to allow the target to pull the update-set. This is why initially the request was made with the CD user.
@gitlabbin I see you point where it's confusing when 'talking' to the source with the deployment user.
The deployment process registers an 'update set source' on the target environment pointing to the source. The credentials for this are: a) taken from the request auth https://github.com/bmoers/sn-cicd-integration/blob/29d3c863756ee7c6abaf466872cda3ea4a641743/script_include/CiCdDeploy.js#L173 or b) generated on the fly https://github.com/bmoers/sn-cicd-integration/blob/29d3c863756ee7c6abaf466872cda3ea4a641743/script_include/CiCdDeploy.js#L210 As mentioned that user must have admin or teamdev_user role.
Options for this: a) revert change and keep CD as initiator for deployment on source b) add teamdev_user role to the CI user, use CI user to connect. c) change the deployment API in sn-cicd-integration to NOT take the user from the request and pass either an additional one or use the generated user
I think this change should be reverted and CD user used for this process. There is an option to have dedicated users per environment for this.
Proposals please
Hi Boris,
Correct me if I am wrong:
getCdClient
function is using only inside deploy-update-set.js
for trigger a remote rest call,
return getCdClient(config).deployUpdateSet(config.updateSet.sys_id, targetHostName, {
username: username,
password: password
})
No impact to the deployment inside of servicenow, that is implemented in sn-cicd-integration
project.
once the the API in sn-cicd-integration get the correct Source user, then it will have privilege to access source,
So the rule is: Source with user from source, Target with user from target, even registers an 'update set source' on the target environment, keep that way, it still working
I did test on my side, everything working fine.
The deployment is a series of calls. First one points to source which then (service now internally) connects to target to register a new update set source.
Can you pls check on your target env what credentials are set here? What roles does the CI user on source have?
Cheers Boris
The idea was to have as less admin grants as possible. For CI that’s no issue, but for CD it needs this privileges. If both users are admin this will for sure work. If only CD is, it won’t.
I’m thinking of changing this API a bit to have all options.....
You are right, I am using admin role for both, the rest api will update the source update set status to 'committed' too, so it will need privilege as well Source Instance user:
user: svc_develop
password: ******
role: admin
Target Instance user:
user: svc_consume
password: ****
role: admin
also having multiple source instances and multiple target instances.
CICD_CI_DEV001_USER_NAME='svc_develop1'
CICD_CI_DEV001_USER_PASSWORD='******'
CICD_CI_DEV002_USER_NAME='svc_develop2'
CICD_CI_DEV002_USER_PASSWORD='*******'
CICD_CD_TST001_USER_NAME='svc_consume01'
CICD_CD_TST001_USER_PASSWORD='*********'
CICD_CD_TST002_USER_NAME='svc_consume02'
CICD_CD_TST002_USER_PASSWORD='*********'
a new feature may need to encrypt the password in side .env config, for some security policy reasons config file can't keep clear password.
a new feature may need to encrypt the password in side .env config, for some security policy reasons config file can't keep clear password.
If you don't want to have passwords in the .env file, you can set the env vars before startup of the service.
As it needs a user which has admin or teamdev_user role I'm going to change the deployment API to look like this:
{
"updateSetSysId": "xxxxxxxxxxxxxxxxxxxxxxxx",
"targetEnvironment": { // the CD user of the target environment or fallback the CI user
"host": "https://targethost.service-now.com",
"username": "",
"password": ""
},
"sourceEnvironment": { // the CD user of the source environment or fallback the CI user
"username": "",
"password": ""
}
}
'sourceEnvironment' will be used to create the 'update set source', the request to that API will be done with the CI user.
I'll keep the '_CICDDEPLOYMENT' creation part but will add a system property to toggle the creation of that user with 'teamdev_user' privileges. In that case there will be no need to have a CD user with admin role at all on the source environment.
@gitlabbin Please have a look at the latest version and the updated documentation https://github.com/bmoers/sn-cicd-example-v3 and https://github.com/bmoers/sn-cicd The deployment process is now supporting GIT artefact checkout. So update sets get deployed directly from the GIT repo instead of a source environment.
I'm also going to present this tool on K19 Tuesday ~10:30 - in case you have plans to join the Knowledge.
Cheers Boris
Great job, I will find some time to try this new feature out. Thanks @bmoers 👍
Issue: config snippet from .env file :
while running deployment jobs, it always using 'admin' to connect to the source instance, it will cause authentication failure