What are the .key files for?

[Martin]

Hi!

I'm currently trying to find out what the files identity.key and
secret.key of the Jenkins installation are for and how I should treat
these.

Note: I've already asked on the [user's mailing list](http://
groups.google.com/group/jenkinsci-users/browse_frm/thread/
c9b49eb27f35666f?hl=en#) and on [SF](http://serverfault.com/questions/
291218/what-are-the-jenkins-hudson-key-files-for)

Any insight appreciated.

cheers,
Martin

[Jerome Lacoste]

Martin,

I am not sure of identity.key. It's a RSA key. That's all I know so far. Looking into it.

As for secret.key, it is used for various security related purposes, including plugin data encryption (https://wiki.jenkins-ci.org/display/JENKINS/Publish+Over+...#PublishOver...-Credentials), security between a master and various types of clients (CLI, JNLP slaves, ...), etc.

It is unique to your instance and exposed to the plugins from the Jenkins model instance.

If you lose this file, it will be regenerated with a different key and I guess you will have to reinstall/restart the CLI or JNLP slaves, reconfigure the configuration data that was encrypted, etc

Some code excerpts that also explain some of its limitations.

core/src/main/java/jenkins/model/Jenkins.java

    /**

     * Secrete key generated once and used for a long time, beyond

     * container start/stop. Persisted outside <tt>config.xml</tt> to avoid

     * accidental exposure.

     */

and core/src/main/java/hudson/TcpSlaveAgentListener.java

* <h2>Security</h2>

 * <p>

 * Once connected, remote slave agents can send in commands to be

 * executed on the master, so in a way this is like an rsh service.

 * Therefore, it is important that we reject connections from

 * unauthorized remote slaves.

 *

 * <p>

 * The approach here is to have {@link jenkins.model.Jenkins#getSecretKey() a secret key} on the master.

 * This key is sent to the slave inside the <tt>.jnlp</tt> file

 * (this file itself is protected by HTTP form-based authentication that

 * we use everywhere else in Hudson), and the slave sends this

 * token back when it connects to the master.

 * Unauthorized slaves can't access the protected <tt>.jnlp</tt> file,

 * so it can't impersonate a valid slave.

 *

 * <p>

 * We don't want to force the JNLP slave agents to be restarted

 * whenever the server restarts, so right now this secret master key

 * is generated once and used forever, which makes this whole scheme

 * less secure.

[Jerome Lacoste]

On Tuesday, July 19, 2011 4:07:13 PM UTC+2, Jerome Lacoste wrote:
Martin,
> I am not sure of identity.key. It's a RSA key. That's all I know so far. Looking into it.

Found more info:

The identity.key is generated by the instance identity extension point / module

https://github.com/jenkinsci/instance-identity-module
https://github.com/jenkinsci/instance-identity-module/blob/master/src/main/java/org/jenkinsci/main/modules/instance_identity/InstanceIdentity.java

    Captures the RSA key pair that identifies/authenticates this instance.
    We wrote this for authenticating Jenkins to MetaNectar, but this should be useful
    wherever we need to authenticate Jenkins against something else.

Nectar is Cloudbees's version of jenkins and I guess that metanectar is some sort of authentication agent for their jenkins cloud ???

I am not aware of its use outside nectar. You might be able to not backup the file without big impact on your instance, but if I were you I would backup it in case it becomes in use somewhere else.

Jerome

[Stephen Connolly]

On 19 July 2011 16:45, Jerome Lacoste <jerome....@gmail.com> wrote:

On Tuesday, July 19, 2011 4:07:13 PM UTC+2, Jerome Lacoste wrote:
Martin,
> I am not sure of identity.key. It's a RSA key. That's all I know so far. Looking into it.

Found more info:

The identity.key is generated by the instance identity extension point / module

https://github.com/jenkinsci/instance-identity-module
https://github.com/jenkinsci/instance-identity-module/blob/master/src/main/java/org/jenkinsci/main/modules/instance_identity/InstanceIdentity.java

    Captures the RSA key pair that identifies/authenticates this instance.
    We wrote this for authenticating Jenkins to MetaNectar, but this should be useful
    wherever we need to authenticate Jenkins against something else.

Nectar is Cloudbees's version of jenkins and I guess that metanectar is some sort of authentication agent for their jenkins cloud ???

No comment on your speculation about an internal name that has been changed by marketing several times since we started writing the code at this point ;-)

 

I am not aware of its use outside nectar. You might be able to not backup the file without big impact on your instance, but if I were you I would backup it in case it becomes in use somewhere else.

I would strongly recommend backing it up.

-Stephen

 

Jerome

[Jerome Lacoste]

On Tuesday, July 19, 2011 6:20:28 PM UTC+2, Stephen Connolly wrote:

Nectar is Cloudbees's version of jenkins and I guess that metanectar is some sort of authentication agent for their jenkins cloud ???

 

No comment on your speculation about an internal name that has been changed by marketing several times since we started writing the code at this point ;-)

:) 

 

I am not aware of its use outside nectar. You might be able to not backup the file without big impact on your instance, but if I were you I would backup it in case it becomes in use somewhere else.

I would strongly recommend backing it up.

For clarification, are you aware of any use of this extension apart from the aforementionned one ?

J

[Stephen Connolly]

not aware of anyone else using yet. but if you need to identify and auth instances, eg from an update center to decide who is allowed to download plugins, etc. then it would make most sense to reuse this for identity of installations

- Stephen

---
Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen

[Martin B.]

Jerome, Stephen - thanks for your input!

After your description I'll just ignore these two files until I need them.

In my original posting, I mentioned whether to include these two files
in my backup:

What I'm really trying to figure out at the moment is whether to include
them in my configuration-files set (I keep all configuration files in SCC).

And since these two files are unique to a specific instance, I think
I'll leave them out of SCC, lest someone (i.e. me, once I've already
forgotten about these files) took the configuration files as template to
create another Jenkins instance and reused these files there.

For a full single-instance backup I agree that including them makes sense.

cheers,
Martin

On 19.07.2011 20:39, Stephen Connolly wrote:
> not aware of anyone else using yet. but if you need to identify and auth
> instances, eg from an update center to decide who is allowed to download
> plugins, etc. then it would make most sense to reuse this for identity
> of installations
>
> - Stephen
>
> ---
> Sent from my Android phone, so random spelling mistakes, random nonsense
> words and other nonsense are a direct result of using swype to type on
> the screen
>
> On 19 Jul 2011 18:23, "Jerome Lacoste" <jerome....@gmail.com

[Bap]

Quoting "Martin B." <0xCDC...@gmx.at>:

> Jerome, Stephen - thanks for your input!
>
> After your description I'll just ignore these two files until I need them.
>
> In my original posting, I mentioned whether to include these two
> files in my backup:
>
> What I'm really trying to figure out at the moment is whether to
> include them in my configuration-files set (I keep all configuration
> files in SCC).
>
> And since these two files are unique to a specific instance, I think
> I'll leave them out of SCC, lest someone (i.e. me, once I've already
> forgotten about these files) took the configuration files as
> template to create another Jenkins instance and reused these files
> there.
>
> For a full single-instance backup I agree that including them makes sense.
>
> cheers,
> Martin
>

I strongly suggest backing up the files somewhere.
As already mentioned in this thread, the secret.key is used to encrypt
sensitive data in configuration files, e.g. the proxy password in
update center. Without the key file these configuration values are
useless.

Bap.