choria-legacy/go-security

Abstraction over various security systems Choria supports

go-security's Issues

support SecurityAlwaysOverwriteCache for the puppet provider

pkcs11: get pin in validate() only

alays ask puppet for ssl dir on windows

os.Geteuid always returns -1 on windows.

Remove go-choria dependency

Relates to choria-io/go-choria#617

should support other callerid patterns than choria=

https://github.com/choria-io/go-security/blob/6440c9b8406c0f45440a8da5bacad016097f00f9/filesec/file_security.go#L310-L319

Limits us to just choria=bob but when using a signer service that service want to set [email protected] or whatever

Support user-selectable list of ciphers

Related to choria-legacy/go-network-broker#75, allow users to select a list of available ciphers at runtime.

Default to a more sensible list.

Support configuration of ECC preferences.

Add tests for server side CA/intermediate chains

A use case not tested for is when the server knows the intermediate CA(s), and the client only provides a single certificate.

Add tests to cover this case.

Create a generic rego evaluator

We have rego now in mcorpc and in aaasvc, we have a fairly solid idea of how this will look for choria so we can probably extract out something generic before we take next steps:

• rego evaluation in provisioning server
• possibly in federation broker to control routing decisions

The basic things we need are:

• send in inputs in a map[string]interface{}
• query to run
• module name
• supply optional functions
• configure path to the rego file to use OR supply the rego file as bytes
• configure tracing or not

Something like:

pass, err := thing.Evaluate(inputs, logger, File(f), Trace())

or

pass, err := thing.Evaluate(inputs, logger, Policy(p), Trace())

And error I guess have to be something like rego errors with extra context associated

We'd also have a configuration Functions(f) which would take a function map to add to the rego runtime like aaasvc does.

This would be rego specific, i dont really have the appetite now to make a whole abstraction that can support other forms of policy engine.

What do you think @vjanelle

go-security filesec should validate before trying to cache

If you change the whitelists, go-security filesec will reference a cached item and not check the identity in the future.

prioritise priv certs when validating

https://github.com/choria-io/go-security/blob/6440c9b8406c0f45440a8da5bacad016097f00f9/filesec/file_security.go#L276-L282

It's typical that privilged certs are going to - when in use - be used for bulk of requests, they should be checked first

email sans in client certificates are not parsed correctly

choria 0.10.

With client certificates containing a subject alternate name of email. e.g.

           X509v3 Subject Alternative Name: 
                othername:<unsupported>, email:[email protected]

the choria server always fails to parse and validate this correctly and results in

{"level":"error","msg":"Could not cache Client Certificate: certificate 'email' did not pass validation","time":"2019-04-12T17:16:28+02:00"}

https://golang.org/src/crypto/x509/verify.go line 756 all SANs are assumed to be DNSnames.

remove missleading warning about privileged certs being cached

When the cert has not changed and SecurityAlwaysOverwriteCache is set we still see lines like below logged while the cert isnt actually being cached:

https://github.com/choria-io/go-security/blob/20b0225a2d5503d1a583518cea788902be351cb0/filesec/file_security.go#L685

check user certs first if they exist

When a user certificate exist and we're checking all possible certs check the user specific one first this way we avoid a bunch of needless privileged checks and related logging

support regex enclosed in slashes for certname_whitelist config

To maintain consistency with mcollectived config, the regex string for this option should work with or without surrounding forward slashes. E.g.:

plugin.choria.security.certname_whitelist = /\.mcollective$/, /\.mco$/

or

plugin.choria.security.certname_whitelist = \.mcollective$, \.mco$

Currently only the latter works.

add means to sign a request using a remote signer

Support signing requests against aaasvc

Support x509.ExtKeyUsageClientAuth

Our mTLS certificates have the x509.ExtKeyUsageClientAuth field set. Crypto/TLS won't validate certificates unless told to accept it.

do not confuse identity and certname

relates to choria-io/go-choria#344

handle option failures

Here:

https://github.com/choria-io/go-security/blob/45bb7647cf407fb149ecab618a57dbaf29f3686b/filesec/file_security.go#L119-L121

and here:

https://github.com/choria-io/go-security/blob/45bb7647cf407fb149ecab618a57dbaf29f3686b/puppetsec/puppet_security.go#L149-L151

errors are silently ignored

Support choria-io/go-choria#476 - Support always overwriting cache

Upstream configuration key change in choria-io/go-choria#476 - Need to make go-security filesec utilize this behaviour.

Disable full schema validation by default

It's just too slow and annoying, but retain the ability

Only overwrite certs when they actually change

When AlwaysOverwriteCache is set overwrites and logs should only happen when they change

Add pkcs11 provider

In my environment, we need to use yubikeys to authenticate everywhere. Adding a pkcs11 provider would allow us to use Choria with our security model.

Support client intermediate chains

If your client sends a list of intermediate certificates, go-security filesec won't understand what to do with them.

This is common in our mTLS use case.

while caching data privilged certs are validated with callerid

When determining if a certificate has to be cached we first check its signed by the CA then if its privileged:

https://github.com/choria-io/go-security/blob/6440c9b8406c0f45440a8da5bacad016097f00f9/filesec/file_security.go#L631-L639

Here though name would be the callerid not the name found in the certificate, we need to parse the certificate and check it using its cert.Subject.CommonName.