Kubernetes authenticator inject_client_cert produces audit record on failure

[micahlee]

Overview

When the authn-k8s /inject_client_cert endpoint fails, it should produce an authentication failed audit event including the failure information.

Currently, the only way to determine the reason for certificate injection failure is to enable DEBUG logging on the Conjur server and view the stack trace in the server logs. This is also different from the the /authenticate endpoint, which does include initial failure information in the audit log.

This is an alternative to logging the top-line error information at the WARN level, and better protects audit failure reasons from leaking any authentication information, since audit records are protected by RBAC.

Technical Notes

Consider the authenticate/ error handling, where all failure causes are audit logged before returning the error to the end user as a generic 401 Unauthorized:

conjur/app/domain/authentication/authenticate.rb

Lines 22 to 32 in 12494b3

	def call
	validate_authenticator_exists
	validate_security
	validate_credentials
	validate_origin
	audit_success
	new_token
	rescue => e
	audit_failure(e)
	raise e
	end

In contrast, inject_client_cert only returns the 401 without logging the failure in the audit records:

conjur/app/controllers/authenticate_controller.rb

Lines 110 to 123 in 12494b3

	def k8s_inject_client_cert
	# TODO: add this to initializer
	Authentication::AuthnK8s::InjectClientCert.new.(
	conjur_account: ENV['CONJUR_ACCOUNT'],
	service_id: params[:service_id],
	csr: request.body.read,
	# The host-id is split in the client where the suffix is in the CSR
	# and the prefix is in the header. This is done to maintain backwards-compatibility
	host_id_prefix: request.headers["Host-Id-Prefix"]
	)
	head :ok
	rescue => e
	handle_authentication_error(e)
	end

conjur/app/domain/authentication/authn_k8s/inject_client_cert.rb

Lines 22 to 26 in 12494b3

	def call
	update_csr_common_name
	validate
	install_signed_cert
	end

[micahlee]

@orenbm @andytinkham @shaharglazner @alexkalish @AndrewCopeland @jtuttle

I'd love to get your take on this proposal to add audit authentication logging to the inject_client_cert endpoint of the Kubernetes authenticator.

In my mind, this would be a shift in direction from logging more information in the Conjur server logs, to making more of this kind of information in the audit log instead.

[orenbm]

I think that regardless to the fact that it's hard to get the error from the logs (which can be tackled in another approach), it makes sense to add an audit message for inject_client_cert as a Conjur user/host performs an access request to Conjur. So I'll +1 for this issue.

[andytinkham]

I agree - I think that it makes sense to include an audit log message. Injecting client certs could potentially open a number of different attacks, and having audit log warnings that someone was trying to get a client cert into the system seems like a good thing. I'm not sure what you're intending that log message to actually say - there's some variants there that would be leaking info, of course - but the idea itself seems sound to me.