feat: Automate Nautobot service account provisioning

[haseebsyed12]

When service account details are created in Vault (PasswordSafe), a Kubernetes
secret is generated. Argo Events then triggers a Job that runs an Ansible
playbook to ensure the user is created in Nautobot and a corresponding token
is provisioned.

[abhimanyu003]

This is looking good, but we need to document the flow using some flow chart + we need to have a table where all the required passwords are listed.

[skrobul]

lgtm, please rebase

[stevekeay]

Under what circumstance does the nautobot API produce 2xx responses with no "result" key in the body? Is it correct to interpret this as "query was successful and there are no tokens", or should this be treated as an error, indicating that the query could not be completed, and/or the results could not be parsed?

[haseebsyed12]

for no tokens

{
    "count": 0,
    "next": null,
    "previous": null,
    "results": []
}

[stevekeay]

In that example the "results" key is present, with a value of the empty list. I was saying that if there is no "results" key at all in the dict, you treat this as the same thing, and I was wondering if that could mask errors from the API. However we are not worrying about errors, so you can ignore this.

[cardoe]

So I'm still struggling to see the deployment configuration here. The questions I've got:

• You'll either need to provide the list of service accounts / tokens that need to be defined in the environment that runs Nautobot (where an admin credential to create that will exist) OR if the individual site environments are defining their own then they'll need the admin credential. This isn't very clear to me from the code which path you intent to take.
• You define a site specific Application deployment of a kustomization.yaml into a site namespace nautobot but to what purpose? The sites need the token credentials in the namespaces where their applications run.

[stevekeay]

Like Doug says, if this is going to run in each site, the credential in passwordsafe would list the "central" nautobot URL, and every site will try to create the user and token in the central nautobot.

Should each site have its own username, like argo.iad3, argo.rxdb-lab, and so on?

[stevekeay]

In that example the "results" key is present, with a value of the empty list. I was saying that if there is no "results" key at all in the dict, you treat this as the same thing, and I was wondering if that could mask errors from the API. However we are not worrying about errors, so you can ignore this.

[haseebsyed12]

Like Doug says, if this is going to run in each site, the credential in passwordsafe would list the "central" nautobot URL, and every site will try to create the user and token in the central nautobot.

Should each site have its own username, like argo.iad3, argo.rxdb-lab, and so on?

yes every site has its own set of secrets.

[haseebsyed12]

So I'm still struggling to see the deployment configuration here. The questions I've got:

* You'll either need to provide the list of service accounts / tokens that need to be defined in the environment that runs Nautobot (where an admin credential to create that will exist) OR if the individual site environments are defining their own then they'll need the admin credential. This isn't very clear to me from the code which path you intent to take.

* You define a site specific Application deployment of a `kustomization.yaml` into a site namespace `nautobot` but to what purpose? The sites need the token credentials in the namespaces where their applications run.

• We define superuser username/pwd and token for site in passwordsafe

• responsibility of global cluster is to create superuser token of site clusters.

• global cluster (staging) creates site cluster (rxdb-lab) secret of super-user and also creates user and token in nautobot.

• Now site cluster only creates secret of super-user it did not do anything in nautobot.

• Now by using site's superuser token. site creates all its other users in nautobot.

• Nautobot store will provide specific application tokens to respective applications in there namespaces.

• Global cluster's superuser token is not used anywhere in site cluster.

[stevekeay]

Let's take one example: the secret that a site's argo-workflows is going to use, containing a token allowing it to log in to Nautobot. In which namespace will that be created?

How was that secret previously created? If it is managed by Argo CD, is there an old manifest that we need to delete?

[haseebsyed12]

Let's take one example: the secret that a site's argo-workflows is going to use, containing a token allowing it to log in to Nautobot. In which namespace will that be created?
Answer: Secret will be created in nautobot namespace and then will be copied to argo-events workflow using nautobot ClusterSecretStore
> How was that secret previously created? If it is managed by Argo CD, is there an old manifest that we need to delete?
Answer: Previously we were using nautobot superuser token only everywhere.
Also I updated the manifest to use new workflow specific token instead of superuser token

na