Is there a way to force all scheduled job runs to be performed by a certain user, instead of the user which enabled the scheduling?
What I meant is the rundeck user, not the node user, like those defined in the realm.properties file.
Let's say I have 2 users defined: user1 and user2.
user1 logs into rundeck and starts a job. In the recent executions list the job will appear as performed "by user1".
user1 now edits the job and enables the "Schedule to run repeatedly" option.
When the job starts on the schedule it will also be reported as ran "by user1".
What I need is a way to tell rundeck that all jobs which have "Schedule to run repeatedly" enabled should be run by another user (such as user2) instead of the user that edited them and enabled the scheduling (user1).
Why do I want this? Two reasons:
1. Cleanliness: I want all automated jobs to be listed as ran by a "rundeck service" user.
2. Issues with LDAP and ACLs: our rundeck users are imported from LDAP and rundeck ACLs are set for LDAP groups. When a job is run on schedule rundeck will not call the LDAP server to retrieve the group list, the user will then be treated as having no group and consequently no ACL and the job will fail because of lack of permissions.
Yes, you can specify a different account via the username attribute for that Node definition.
Related
My Rundeck detail Rundeck version: 4.10.0
install type: DEB
OS Name/version: Debian 11
DB Type/version: h2
A LDAP user without a Role membership can properly login but can not see any Projects - so far fine.
How can i block such a user to Login at all?
We have one "userBaseDn" Group (userBaseDn="cn=Users,ou=PROD,dc=company,dc=com") in which all users are stored. But of course, only users in following roleBaseDn (roleBaseDn="cn=Rundeck_Admins,cn=Applications,ou=PROD,dc=company,dc=com") Group should have access to Rundeck Web UI.
I expect, only users in Group "Rundeck_Admins" can Login to Rundeck at all
Currently, you can only restrict that using an ACL policy (the user can log in but cannot view/edit/run any project/job, as you say), please take a look at this.
Alternatively, you can create a specific branch in your LDAP server only for Rundeck users.
Currently, means there will be a change on this behavior?
As far a i understand LDAP right, for a specific LADP branch in which a place users, i have to manage users twice. 1st, in user directory and 2nd in the specific Rundeck Group. For me quite unhandy...
I am new to creating jobs in Rundeck (community). I'd like to create a job under a project that accepts 2 parameters from the user (1. external/internal 2. IP CIDR) and then return if the IP CIDR already exists in WAF.
The current process is that user passes these parameters and the script has aws-vault command for the user to authenticate with the AWS account.
I have a shell script to do so but wondering how to do this using Rundeck jobs. Also, is there a way to allow the entire Rundeck instance (IAM roles?) to authenticate against a certain AWS account?
Thanks in advance.
To execute a script on Rundeck:
Create a new Project, create a new job, give it a name, on the workflow tab select the "Script" step (you can pass the parameters on the "arguments" textbox) put the parameters on the ), put the script content there, and save and run the job.
Create a new Project, create a new job, give it a name, on the workflow tab select the "Script file or URL" step (you can pass the parameters on the "arguments" textbox), put the script file path there, and save and run the job.
I have a shell script to do so but wondering how to do this using
Rundeck jobs. Also, is there a way to allow the entire Rundeck
instance (IAM roles?) to authenticate against a certain AWS account?
For EC2 remote instances, S3 actions, and some specific (and exclusive) Process Automation it's possible (the credentials are part of the plugin config).
For AWS WAF you can create a script using awscli tool with the rights parameters to execute it (or design your own AWS WAF plugin).
Anyway, take a look at the basic tutorial to learn how Rundeck works.
I have an existing, functional Dataproc workflow template, and I am attempting to create a Cloud Scheduler job to run it on a schedule. The workflow template runs without error when run via the "RUN" button on the Dataproc Workflow Template console page.
I created a Scheduler job to run this workflow template with the following command (names redacted here):
gcloud scheduler jobs create http <job-name>
--location=us-central1
--schedule="0 1 * * *"
--http-method=POST
--uri=https://dataproc.googleapis.com/v1/projects/<project-name>/regions/us-central1/workflowTemplates/<template-name>:instantiate?alt=json
--oauth-service-account-email=<service-account-name>#<project-name>.iam.gserviceaccount.com
--oauth-token-scope=https://www.googleapis.com/auth/cloud-platform
The job is successfully created, but upon attempting to run it, it returns INVALID_ARGUMENT. Here is the response:
{"#type":"type.googleapis.com/google.cloud.scheduler.logging.AttemptFinished", "jobName":"projects/<project-name>/locations/us-central1/jobs/<job-name>",
"status":"INVALID_ARGUMENT", "targetType":"HTTP", "url":"https://dataproc.googleapis.com/v1/projects/<project-name>/regions/us-central1/workflowTemplates/<workflow-name>:instantiate?alt=json"}
I get no more descriptive response than that. There is no sign the workflow began, nor any failures listed on the Dataproc Workflow console page.
I also tried a similar Scheduler job with the same service account, scope, location, and schedule, but I cut the URL down to the base workflow location: https://dataproc.googleapis.com/v1/projects/<project-name>/regions/us-central1/workflowTemplates/<template-name> and tried --http-method=GET, and that was successful, but, of course, does not instantiate the workflow.
Is there either something I'm missing, or is there at least a better way to diagnose the issue?
I have now been able to successfully kick off this workflow via Scheduler once the Service Account User role has been added to the service account that is used in creating the Scheduler job. That is, the service account itself also needs to be a service account user.
So my goal is to create a Rundeck job that runs on a schedule and isn't run as my personal user, or any "regular" user, but rather a bot user. Ideally this bot user wouldn't have login access and restricted permissions for security reasons, but would be able to run certain jobs. I've tried searching, but the only information I'm finding is about how to create a "regular" user in Rundeck. Even if I go down that route of creating the bot user as a "regular" user, to use it, you need to pass in either the login credentials or an API token. An API token would be fine, if it could be generated and pulled in on the fly. However, that is not the case, the API has an expiration itself. If there is something I'm missing, please let me know. I'd love to get this working.
Rundeck Version: Rundeck 3.2.1-20200113
Rundeck Cli Version: 1.1.7
You can set the following configuration in your rundeck-config.properties file (usually at /etc/rundeck/ directory):
rundeck.api.tokens.duration.max=0
This will disable your maximum period, you can see this in the official documentation here.
With that, your "bot user" can do it through API / RD CLI as you wrote.
Try using webhooks https://docs.rundeck.com/docs/manual/12-webhooks.html
You can trigger a job by making a http-request
The way I've implemented bots is as a user who is a member of a 'bot' user group, with ACLs that lock down that group as required. Any passwords required for the scheduled job are loaded into the key storage of the bot user.
With this approach you still need someone who knows the bot credentials to login as them and set passwords/SSH keys, but that's a one-off. Is that what you're trying to avoid?
The one annoying thing I've found is that a scheduled job always seems to run as the last user to edit the job - so I grant edit access to bot users and make sure to set/reset the schedule after any edit by a normal user. Hoping to address this through https://github.com/rundeck/rundeck/issues/1603, you might want to give it a 👍.
Problem Scenario:
OKD cluster is having two cluster-admins: User1 and User2.
If User1 connects to cluster using ssh and performs oc login and parallely User2 connects to the same cluster with new ssh session and performs oc login.
Now when User1 checks oc whoami the result will be User2 (which is desired to have User1). This will create problems like User1 operations(ex:deployements) to clash with User2.
How can this problem be eliminated so that two users can parallelly use the cluster?
Note: Both User1 and User2 are configured with LDAP, is this creating problem?
How can this problem be eliminated so that two users can parallelly use the cluster?
AFAIK, the OKD session is saved in $HOME/.kube/config by default. So it depends on a OS account session. If you'd like to use at the same time, then you should use different OS account each other. OR you should run oc login --config context_file_path per each execution for saving session to different context file. Refer Loading and Merging Rules
for more details.
Note: Both User1 and User2 are configured with LDAP, is this creating problem?
No. Identity provider configuration does not affect this.
You should not share user accounts in this way. Each person who is logging in to the cluster should using a command-line client be doing so under their own linux uid against their own home directory. Sharing user accounts is a security vulnerability and removes your ability to track who is doing what.
kubectl and oc take this as a prerequisite, which is why you're running into this issue.